This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: C++11 atomic library notes

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

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]