[cpp-threads] Draft Plan for Threads in C++

[Boehm, Hans]

I would actually lean towards "always implemented, with feature tests
to determine whether it's an emulation".

I'm not sure that the IA64 example below is very good, since you
can emulate fetch_and_add with CAS if the fetch_and_add operand
has the wrong form,and the performance impact of that is usually
small.  (The obvious emulation is not wait-free, but we probably
don't want to promise that anyway.)

Hans

> -----Original Message-----
> From: 
> Cpp-threads_decadentplace.org.uk-bounces at decadentplace.org.uk 
> [mailto:Cpp-threads_decadentplace.org.uk-bounces at decadentplace
> .org.uk] On Behalf Of Ben Hutchings
> Sent: Friday, April 29, 2005 6:00 PM
> To: cpp-threads
> Subject: Re: [cpp-threads] Draft Plan for Threads in C++
> 
> 
> Lawrence.Crowl at Sun.com wrote:
> > Ben Hutchings <ben at decadentplace.org.uk> writes:  
> > >Lawrence.Crowl at Sun.com wrote:  >> "Boehm, Hans" 
> <hans.boehm at hp.com> 
> > writes:  >>  >Should it provide specific "atomic" classes like the 
> > Java one?  >>  >Should it be a template on arbitrary types, 
> which can 
> > just say "not  >>  >implemented" if you ask for atomic 276 byte 
> > structs with overloaded  >>  >assignment?  Do we agree that the 
> > operations should be (op,  >>  >ordering_constraint) pairs?  Is the 
> > ordering_constraint a template  >>  >parameter?  What about 
> optional 
> > hardware-dependent functionality?  >>
> >  >> All good questions.  My current thinking is to keep it 
> simple, e.g. a
> >  >> few lock objects, an atomic integer with atomic += operations, a
> >  >> compare-and-swap operation.
> >  ><snip>
> >  >
> >  >With respect, I think this is naive.  Where available, 
> atomic += may be
> >  >highly constrained; for example on IA64 it can add or 
> subtract 1, 4, 8
> >  >or 16.  CAS isn't universally available and on the ARM 
> architecture it
> >  >probably still won't be commonly available in 2009 
> without OS support.
> >  >If I'm not mistaken, most lockless algorithms require ordering
> >  >constraints.
> > 
> > Implicitly, I was assuming that the ability to write lockless 
> > algorithms was a goal for the work.
> 
> Exactly, and I don't think a "simple" interface will support 
> that well. Maybe I misunderstood what you said, but it 
> sounded like you were advocating that a common set of atomic 
> operations should be required across all implementations (or 
> all that support multiple threads).  I believe that would 
> result in the standard being ignored either by implementers, 
> because they can't practically support the whole set on some 
> target hardware, or by users, because they find the set 
> inadequate for high performance on multiprocessor systems, or 
> even both groups.  If you already agree that the availability 
> of some operations could be implementation-defined, ignore me.
> 
> Ben.
> 
> -- 
> Ben Hutchings
> Time is nature's way of making sure that everything doesn't 
> happen at once.
> 
> -- 
> cpp-threads mailing list
> cpp-threads at decadentplace.org.uk 
> http://decadentplace.org.uk/mailman/listinfo/cpp-threads_decad
entplace.org.uk