Re: [boost] [atomic] Availability detection

Subject: Re: [boost] [atomic] Availability detection
From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2010-01-31 06:57:08

On 01/31/2010 02:32 PM, Helge Bahmann wrote:
> Am Sunday 31 January 2010 10:07:02 schrieb Andrey Semashev:
>> Hi,
>>
>> Will there be a way to detect if specific operations over a specific
>> type are available atomically on the current platform?
>
> All operations on all types will always be atomic. The implementation
> transparently falls back to using locking internally if there is no way to
> guarantee atomicity otherwise.
>
> What you could want to detect is lock-freedom, and this is defined per type:
> either all operations on a type are lock-free, or none is. Currently the only
> way is querying the "is_lock_free" property at run-time, but there should
> probably be macros for querying at compile-time.

So, will you add them to your library?

>> That is, if I
>> know that atomic operations are emulated with locks, I want to fall back
>> to another branch of my code with explicit locks, rather than the
>> emulated atomics.
>
> Yes, this would be rather useful. Currently I know of one corner case
> (uint64_t on x86_32) where this distinction would actually have to be made at
> run-time.

Why is it not possible to detect it in compile time? x86 since Pentium 
has cmpxchg16b, which can be used to implement all other operations. If 
I compile my code to run on x86 since Pentium (which I believe 99% of 
cases), I should be able to use lock-free atomics and detect that with 
macros. This might require a configuration macro for Boost.Atomic, if 
there is no way to detect that option from the compiler, but at least 
GCC does allow to detect that.