Subject: Re: [boost] [atomic] comments
From: Helge Bahmann (hcb_at_[hidden])
Date: 2011-10-21 06:09:50
Hi Tim and others
On Friday 21 October 2011 10:27:50 Tim Blechmann wrote:
> hi helge and others,
> ... has been rather quiet about the boost.atomic review, so i want to raise
> a view issues:
> shared memory support:
> the fallback implementation relies on the spinlock pool that also used by
> the smart pointers. however this pool is per-process, so the fallback
> implementation won't work in shared memory. can this be changed/fixed?
fixing this would require a per-variable lock... depending on the platform
this can have enormous overheads.
I would suggest using the compile-time macros BOOST_ATOMIC_*_LOCK_FREE to pick
an alternate code path.
> is_lock_free is set to either `true' or `false'. however in some cases,
> there are alignment constraints (iirc, 64bit atomics on ia32/x86_64 require
> a 64bit alignment). afaict there are not precautions to take care of this,
> are there?
for x86_64 there is nothing to do, ABI requires 8 byte alignment already
there used to be an __align__(8) to cover ia32, but it got lost... I *think*
the "lock" prefix will cover this case nevertheless (at a hefty performance
> compile-time vs run-time dispatching:
> some instructions are not available on every CPU of a specific
> architecture. e.g. cmpxchg8b or cmpxchg16b are not available on all
> ia32/x86_64 cpus. i would appreciate if these instructions would not be
> used before performing a CPUID check, whether these instructions are really
> available (at least in a legacy mode)
the correct way to do that is to have different libraries for
sub-architectures and have the runtime- linker decide... this requires
infrastructure not present in boost
> currently cmpxchg16b doesn't seem to be supported. this instruction is
> required for some lock-free data structures (e.g. there is a dequeue
> algorithm, that requires a pair of tagged pointers).
could do, but cmpxchg16b is dog-slow, the fallback path is going to be faster
> maybe this can be a starting point to discuss boost.atomic ...
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk