[PATCH] D17950: Implement is_always_lock_free

[Joerg Sonnenberger via cfe-commits]

On Fri, Mar 18, 2016 at 12:11:22PM -0500, Craig, Ben via cfe-commits wrote:
> A lot of it is a frontend decision.  What goes in the libcall feels an awful
> lot like the 386 vs 486 example that I hear a lot.  If I want one binary
> that can run on both a 386 (very limited atomic support) and a 486 (a bit
> more atomic support), then I generate the binary such that it has library
> calls to atomic routines.  The library on the 386 uses the global lock
> shard, and the library on the 486 uses native instructions.  The same kind
> of thing would apply for one byte atomics when only four byte atomics have
> hardware support.  The library call would use the lock shard as the default.
> If the platform doesn't have byte granularity memory protection a different,
> lockless implementation could be used that loads the surrounding four bytes
> instead and does all the masking.

The situation here is quite different. If you have a way to do lock-free
CAS for 32bit, you can implement it for 16bit and 8bit as well. On other
hand, if you do not have a lock-free CAS of a given size, it can be
implemented as lock-free libcall only if (a) no such MP configuration
exists and (b) (non-atomic) load/store of that size is supported. I'm
not even sure if such a thing as a SMP i386 ever existed, given that the
APIC specifications are all for i486 and later.

Joerg