Re: [boost] Fw: [atomic] review results

Subject: Re: [boost] Fw: [atomic] review results
From: Helge Bahmann (hcb_at_[hidden])
Date: 2011-11-08 05:54:54

On Tuesday 08 November 2011 11:22:07 Tim Blechmann wrote:
> hi helge,
>
> > I think that there is value in trying to maintain
> > sizeof(boost::atomic<T>) == sizeof(std::atomic<T>) whatever this is going
> > to mean per platform, and part of the thing I have in my mind is indeed
> > interprocess-safety. I also don't think that Boost.Atomic it is in that
> > state currently, but I am a bit reluctant to make a decision that might
> > shut down this path forever.
>
> then how do other compilers/library implementations behave? you said that
> gcc doesn't follow the suggestion of the standard to avoid per-process
> states.

well gcc certainly follows the recommendation of the standard by making the 
*lock-free* atomics both address-free and free from process state, I don't 
read the standard as suggesting (or even requiring) anything for emulated 
atomics

> but what about msvc or clang/libc++? 

libc++ atomic is not yet completed, but does not intend to use a per-object 
lock. As I read it, they do in fact consider mutex (pool?) instead of 
spinlock. msvc I don't know yet.

> > > * i could imagine that c++11 compilers may be smart enough to pad
> > > adjacent std::atomic<> to ensure that they are placed in separate cache
> > > lines.
> >
> > uhh, I hope they *don't* do that as it has grave implications on the ABI
> > (currently the compiler would not be allowed to "fill" the hole with
> > other data members), and cacheline sizes vary by processor generation
>
> cacheline sizes vary, but a compiler might optimize for a commonly used
> value. however i've been hit more than once by compilers, which are
> changing the size of structs.

under what circumstances did the sizes change? Currently I cannot imagine this 
*not* being an ABI violation

> > > > Another option that I have considered would be "piggy-backing" the
> > > > spinlock
> > > > pool into Boost.Thread -- the idea is that an application is either
> > > > single-threaded, or if it is multi-threaded it is expected to link
> > > > with
> > > > Boost.Thread (even if nothing from Boost.Thread is used indeed, yes
> > > > makes me feel uneasy as well).
> > >
> > > this would imply that boost.thread cannot be used as static library any
> > > more.
> >
> > That would indeed be bad, but I don't understand why this would be in
> > conflict, could you explain a bit further?
>
> don't you need a shared library to resolve the spinlock pool?

Frankly I don't know the answer yet so have to experiment.

Best regards
Helge