Memory model release/acquire mode interactions of relaxed atomic operations

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



The GCC Wiki says this about the memory model synchronization mode
[Acquire/Release][1]:

> To make matters a bit more complex, the interactions of non-atomic
> variables are still the same. Any store before an atomic operation
> must be seen in other threads that synchronize. For example:
> 
> |  -Thread 1-
> |  y = 20;
> |  x.store (10, memory_order_release);
> | 
> |  -Thread 2-
> |  if (x.load(memory_order_acquire) == 10)
> |     assert (y == 20);
> 
> Since 'y' is not an atomic variable, the store to 'y' _happens-before_
> the store to 'x', so the assert cannot fail in this case. The
> optimizers must still limit the operations performed on shared memory
> variables around atomic operations.

Now, what if I make 'y' an atomic variable (without imposing
_happens-before_ restrictions)?

|   -Thread 1-
|   y.store (20, memory_order_relaxed);
|   x.store (10, memory_order_release);
| 
|   -Thread 2-
|   if (x.load(memory_order_acquire) == 10)
|      assert (y.load (memory_order_relaxed) == 20);

Can the assert fail? Are there fewer requirements for atomic variables
than for non-atomic variables? Or is the Wiki's restriction to
non-atomic variables gratuitous and misleading here?

[1]: https://gcc.gnu.org/wiki/Atomic/GCCMM/AtomicSync#Acquire.2BAC8-Release

-- 
Regards,
Dietmar Schindler




[Index of Archives]     [Linux C Programming]     [Linux Kernel]     [eCos]     [Fedora Development]     [Fedora Announce]     [Autoconf]     [The DWARVES Debugging Tools]     [Yosemite Campsites]     [Yosemite News]     [Linux GCC]

  Powered by Linux