Subject: Re: [boost] [atomic] Availability detection
From: Helge Bahmann (hcb_at_[hidden])
Date: 2010-01-31 07:22:14
Am Sunday 31 January 2010 12:57:08 schrieb Andrey Semashev:
> 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?
Yes, as definable macros, indicating for each type the following options:
- atomic<T> is always lock-free
- atomic<T> is never lock-free
- atomic<T> may or may not be lock-free, please check at run-time
Having these macros available makes some of the existing template-magic
redundant, so I am still thinking how to reorganize things to eliminate this
redundancy.
(Handling and testing all of the above possibilities is probably turning out
to be fun :)
> >> 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.
(you mean cmpxchg8b probably) Because the compiler cannot always know if you
might intend to run the code on a 486 unless you explicitly tell it?
FWIW if you pass -march=i686 to gcc then the compiler will unconditionally
generate code that cannot run on 486 (cmov & friends), Boost.Atomic will
detect that case as well and also unconditionally generate cmpxchg8b. If you
do *not* pass this flag, the decision whether to use cmpxchg8b can only be
made at runtime.
Helge