Re: About spinlock implementation
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).
Re: About spinlock implementation
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. ;)
Re: About spinlock implementation
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
Re: About spinlock implementation
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?
Re: About spinlock implementation
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. :)
Re: About spinlock implementation
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(, 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
