I found an implementation of spinlock in concurrency.d.
```
static shared struct SpinLock
{
    void lock() { while (!cas(&locked, false, true)) { Thread.yield(); } }
    void unlock() { atomicStore!(MemoryOrder.rel)(locked, false); }
    bool locked;
}
```
Why atomicStore use MemoryOrder.rel instead of MemoryOrder.raw?

On Thursday, 1 September 2016 at 06:44:13 UTC, mogu wrote:
> I found an implementation of spinlock in concurrency.d.
> ```
> static shared struct SpinLock
> {
>     void lock() { while (!cas(&locked, false, true)) { Thread.yield(); } }
>     void unlock() { atomicStore!(MemoryOrder.rel)(locked, false); }
>     bool locked;
> }
> ```
> Why atomicStore use MemoryOrder.rel instead of MemoryOrder.raw?

I'm not sure I understand rel [0], but raw is too weak. Raw means no sequencing barrier, so

  local_var = protected_value;
  spinlock.unlock();

could be transformed (by compiler or CPU) to

  spinlock.unlock();
  local_var = protected_value;

This effectively makes the access to the protected value unprotected and nullifies the effect of the spinlock.

I find the documentation on MemoryOrder lacking about the semantics of rel. :(

[0] https://dlang.org/library/core/atomic/memory_order.html

On Thursday, 1 September 2016 at 07:46:04 UTC, qznc wrote:
>
> I'm not sure I understand rel [0], but raw is too weak. Raw means no sequencing barrier, so
>
>   local_var = protected_value;
>   spinlock.unlock();
>
> could be transformed (by compiler or CPU) to
>
>   spinlock.unlock();
>   local_var = protected_value;
>
> This effectively makes the access to the protected value unprotected and nullifies the effect of the spinlock.
>
> I find the documentation on MemoryOrder lacking about the semantics of rel. :(
>
> [0] https://dlang.org/library/core/atomic/memory_order.html

Thanks very much. I finally got it. :)

On Thursday, 1 September 2016 at 07:46:04 UTC, qznc wrote:
>
> This effectively makes the access to the protected value unprotected and nullifies the effect of the spinlock.
>

So the cas operation implicit an MemoryOrder.acq? Does it make any other MemoryOrder guarantee?

On Thursday, 1 September 2016 at 07:46:04 UTC, qznc wrote:
>
> I find the documentation on MemoryOrder lacking about the semantics of rel. :(
>
> [0] https://dlang.org/library/core/atomic/memory_order.html

What helped me was to read std::memory_order documentation
http://en.cppreference.com/w/cpp/atomic/memory_order

On Thursday, 1 September 2016 at 10:30:12 UTC, Guillaume Piolat wrote:
> On Thursday, 1 September 2016 at 07:46:04 UTC, qznc wrote:
>>
>> I find the documentation on MemoryOrder lacking about the semantics of rel. :(
>>
>> [0] https://dlang.org/library/core/atomic/memory_order.html
>
> What helped me was to read std::memory_order documentation
> http://en.cppreference.com/w/cpp/atomic/memory_order

Yes, but how do they map? Is D's rel = relaxed or release or acq_rel?

Also, reading C++ documentation should not be required of course. ;)

On Thursday, 1 September 2016 at 10:38:07 UTC, qznc wrote:
> On Thursday, 1 September 2016 at 10:30:12 UTC, Guillaume Piolat wrote:
>> On Thursday, 1 September 2016 at 07:46:04 UTC, qznc wrote:
>>>
>>> I find the documentation on MemoryOrder lacking about the semantics of rel. :(
>>>
>>> [0] https://dlang.org/library/core/atomic/memory_order.html
>>
>> What helped me was to read std::memory_order documentation
>> http://en.cppreference.com/w/cpp/atomic/memory_order
>
> Yes, but how do they map? Is D's rel = relaxed or release or acq_rel?
>
> Also, reading C++ documentation should not be required of course. ;)

MemoryOrder.rel must be std::memory_order::release (70% confidence)
And std::memory_order::relaxed is MemoryOrder.raw of course (90% confidence).