Re: C++11 atomic library notes

[Marc Glisse <marc dot glisse at inria dot fr>]

On Sat, 1 Oct 2011, Andrew MacLeod wrote:

> On 10/01/2011 02:55 AM, Marc Glisse wrote:
> > "The compiler must ensure that for any given object, it either ALWAYS 
> > inlines lock free routines, OR calls the external routines. For any given 
> > object, these cannot be intermixed."
> >
> > Why? You give an example explaining why it is fine to link 386 and 486 
> > objects, and I cant see the difference. Not that I'm advocating mixing 
> > them, just wondering whether it really matters if it happens (by accident).
>
> If we have an architecture which we cannot generate one of the functions for, 
> say __atomic_load_16, then it will have to use whatever the library supplies. 
> If you continues to generate all the rest of the __atomic builtins for 16 
> bytes using lock free instructions, and the call to the library turns out to 
> be a locked implementation at runtime, then atomic support for 16 byte 
> objects is broken. The load thinks its getting a lock, but none of the other 
> routines pay any attention to locks. So if one atomic operations requires 
> then library, they all do in order to get consistent behaviour.

Ah ok, I had understood:
* if __atomic_store_8 is inlined on line 18, it should also be inlined on 
line 42

when instead it is:
* we can't have a locked addition and a lock-free subtraction (hence the 
__atomic_is_lock_free which only takes a size as argument)

Makes perfect sense, thank you for the precision.

By the way, does it make sense to work atomically on a 16 byte object, and 
also work atomically on its first 8 bytes, thus potentially requiring 
__atomic_is_lock_free not to depend on the size?

--
Marc Glisse