|
Boost : |
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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk