Use acquire-release memory order for mutex::try_lock

[louiswilliams]

Mutex locking needs to have memory-order acquire semantics. Imagine two threads incrementing a counter, protected by a mutex:

Preconditions:

• Mutex atomic owner = nullptr
• Non-atomic variable X = 0

Each thread:

1. mutex::try_lock successfully performs owner.compare_exchange_strong(self, memory_order_release). This only guarantees that any preceding reads and writes are not reordered after this one.
2. X = X + 1. This is not an atomic variable and therefore depends on the memory ordering of owner to synchronize reads and writes.
3. mutex::unlock calls owner.store(nullptr) which has seq ordering. This guarantees no preceding or subsequent reads or writes will be reordered.

But because the CAS uses release memory ordering, other threads can reorder 2 before 1 and 3.

This ordering is therefore possible:

Thread 1	Thread 2
2. X=X+1, X=1
	2. X=X+1, X=1
	1. lock
	3. unlock
1. lock
3. unlock

Both threads read X as 0 and both set X to 1. The end state is that X=1, but it should be 2.

Using acquire semantics for the try_lock guarantees that 2 can only happen after 1 and before 3.

[beef9999]

I can recall the old version gcc has immature support for the memory_order_acq_rel . Don't know what's going on today...

[louiswilliams]

x86 does not have this problem. Only ARM supports the acquire, release, and relaxed memory semantics. With this change, I am able to fix a bug in my workload.

[beef9999]

Is the change compatible to x86?
Can you merge this change to release/0.7?

[louiswilliams]

This has no effect on x86. Updated to merge into release/0.7

[lihuiba]

Is the change compatible to x86?

Yes