
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