[cpp-threads] atomics (was: Draft Plan for Threads in C++)

[Boehm, Hans]

I guess my previous statement was oversimplified.
There are really several cases here.  In my limited experience
with my package, on architectures on which you don't have CAS, you
really both want to know that, and you often want to have an emulation
available.  The same goes for fetch-and-add.  I'm not sure what
you want to do if you have fetch-and-add but not CAS.  Are there
such architectures?

On the other hand, if you're missing a double CAS or one of the
multiple flavors of wide CAS (Intel EM64T and IA64 disagree :-( ),
there's no real point in emulating it, since you would lose
fast CAS in the process.  User code needs to handle that case.

I'm not quite sure what the best way is to reflect that in the
interface.

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 Peter Dimov
> Sent: Saturday, April 30, 2005 3:38 AM
> To: cpp-threads at decadentplace.org.uk
> Subject: Re: [cpp-threads] Draft Plan for Threads in C++
> 
> 
> Boehm, Hans wrote:
> > I would actually lean towards "always implemented, with 
> feature tests 
> > to determine whether it's an emulation".
> 
> My vote goes to "implementation defined if unimplementable in 
> a lock-free 
> manner on the platform."
> 
> I'm not sure whether we should acknowledge one possible 
> emulation strategy 
> that uses the variable being manipulated as a spinlock by reserving a 
> sentinel value. 
> 
> 
> -- 
> cpp-threads mailing list
> cpp-threads at decadentplace.org.uk 
> http://decadentplace.org.uk/mailman/listinfo/cpp-threads_decad
entplace.org.uk