Re: [boost] [atomic] comments

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.

> atomic::is_lock_free():
> 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 
cost, though...)

> 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

> cmpxchg16b:
> 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 
anyways

> maybe this can be a starting point to discuss boost.atomic ...

best regards
Helge