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]
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
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
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'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 =
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); }
