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

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

On Tuesday 08 November 2011 12:30:58 you wrote:
> > > 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
>
> in my reading the sentence `The implementation should not depend on any
> per- process state' is not restricted to lock-free atomics, but i am not a
> native speaker and i could be wrong.

neither am I but from the following full excerpt as quoted by Peter Dimov:

[ Note: Operations that are lock-free should also be address-free. That is, 
atomic operations on the same memory location via two different addresses 
will communicate atomically. The implementation should not depend on any 
per-process state. This restriction enables communication by memory that is 
mapped into a process more than once and by memory that is shared between 
two processes. —end note ]

I think that "address-free" clearly applies only to "lock-free", and if 
something is not "address-free" then the point whether it can be used 
interprocess is kind of moot as it is most certainly not going to be mapped 
at the same address (if you consider numerically identical addresses in 
different spaces to be the same at all).

> > > 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
>
> iirc a struct { int i; void*p}; had a size of 16 bytes or 12 bytes
> depending if it was packed or not.

if you apply __attribute__((packed)) yes, but note that this is per-structure 
and (hopefully) not affected by compiler flags

Best regards
Helge