8

In C++ we have keyword volatile and atomic class. Difference between them that volatile does not guarantees thread-safe concurrent reading and writing, but just ensures that compiler will not store variable's value in cache and instead will load variable from memory, while atomic guarantees thread-safe concurrent reading and writing.

As we know, atomic read operation indivisible, i.e. neither thread can not write new value to variable while one or more threads reading variable's value, so I think that we always read the latest value, but I'm not sure :)

So, my question is: if we declare atomic variable, do we always get the latest value of the variable calling load() operation?

TwITe
  • 188
  • 1
  • 11
  • "*but just ensures that compiler will not store variable's value in cache and instead will load variable from memory"* - That's not it, really. It just ensures the value is accessed "strictly according to the rules of the abstract machine". The C++ standard and its abstract machine know nothing of caches. So you can't assume that there's no cache access. – StoryTeller - Unslander Monica Oct 28 '18 at 14:07
  • 2
    this is not what atomic afford: it affords you will have a consistent value (that means you will always read a value that was actually set, not a transient value) But that does not mean the last value... the race remain, but at least values are good – OznOg Oct 28 '18 at 14:08
  • https://stackoverflow.com/questions/36496692/should-stdatomic-be-volatile – user202729 Oct 28 '18 at 14:08
  • @OznOg I think i got you, but in what cases we get a stale value, but not the latest value? – TwITe Oct 28 '18 at 14:16
  • without synchronization, thread can run in random order, thus one may be sleeping for a long time while another never stopped running; you may simulate this just adding `sleep()` in one thread (that is a common way to highlight races) – OznOg Oct 28 '18 at 14:20
  • @OznOg to be precise, it affords "immediate" consistency. read operation will eventually return the latest value no matter if it is atomic or not, therefore non-atomic read operation is referred to as "eventually consistent" – mangusta Oct 28 '18 at 14:20
  • @mangusta -- there is no requirement in the C++ language that non-atomic read operations will eventually return the latest value. If two or more threads are accessing the same object and at least one of those threads is modifying the object you have a **data race**; the behavior of a program that has a data race is undefined. It may well be that in practice you'll eventually see the latest value, but that's outside what the language definition provides. – Pete Becker Oct 28 '18 at 14:55
  • This question is somewhat problematic because the concept of 'latest' is not well-defined for plain stores and loads. If thread 1 changes an atomic variable from 'A' to 'B' and a load in thread 2 returns the value 'A', either the load did not return the latest value or it was scheduled before the store.. there is no way you can tell. – LWimsey Oct 28 '18 at 20:46
  • @LWimsey If some thread changes a variable 'A' to 'B' than creates a file, and another thread sees the file and reads 'A', it's well defined that it isn't the latest value. But in general "latest" is ill defined. – curiousguy Nov 11 '18 at 07:32

2 Answers2

1

When we talk about memory access on modern architectures, we usually ignore the "exact location" the value is read from.

A read operation can fetch data from the cache (L0/L1/...), the RAM or even the hard-drive (e.g. when the memory is swapped).

These keywords tell the compiler which assembly operations to use when accessing the data.

volatile

A keyword that tells the compiler to always read the variable's value from memory, and never from the register.

This "memory" can still be the cache, but, in case that this "address" in the cache is considered "dirty", meaning that the value has changed by a different processor, the value will be reloaded.

This ensures we never read a stale value.

But, if the type declare volatile is not a primitive, whos read/write operations are atomic (in regard to the assembly instructions that read/write it) by nature, we might read an intermediate value (the writer managed to write only half of the bytes by the time the reader read it).

atomic

And the compiler sees a load (read) operation, it basically does the exact same thing it would have done for a volatile value, except for using atomic operations (This means that we will never read an intermediate value).

So, what is the difference???

The difference is cross-CPU write operations. When working with a volatile variable, if CPU 1 sets the value, and CPU 2 reads it, the reader might read an old value.

But, how can that be? The volatile keyword promises that we won't read a stale value!

Well, that's because the writer didn't publish the value! And though the reader tries to read it, it reads the old one.

When the compiler stumbles upon a store (write) operation for an atomic variable it:

  • Sets the value atomically in memory
  • Announces that the value has changed

After the announcement, all the CPUs will know that they should re-read the value of the variable because their caches will be marked "dirty".

This mechanism is very similar to operations performed on files. When your application writes to a file on the hard-drive, other applications may or may not see the new information, depending on whether or not your application flushed the data to the hard-drive.

If the data wasn't flushed, then it merely resides somewhere in your application's caches and visible only itself. Once you flush it, anyone who opens the file will see the new state.

Daniel Trugman
  • 6,930
  • 17
  • 39
  • "writer didn't publish the value" Does that mean that writer has modified value, but not has written value to variable (like read-modify-write steps)? And so reader will see old value because writer hasn't done `write` step? – TwITe Oct 28 '18 at 16:33
  • 1
    Yes, the writer will see the modified value, but other won't. A variable is syntactic sugar for programmers, so you can't actually say that the value "has not written value to variable", but you should rather say "has not published the new value to other CPUs". It's just like the `flush()` command for hard-disk operations. When you write something to a file, others don't see it because you didn't flush it to the hard-disk, instead, it sits somewhere around in your app's caches and visible only to itself. – Daniel Trugman Oct 29 '18 at 08:11
  • But, what if writer can not write value to variable in single instruction? What behaviour in that case, if there's two threads: first thread writes value to variable, and second thread reads value of this variable? Both operations are atomic. So I guess compiler will use cas-loops: If second thread can not atomically read value (because there's thread that writes value), it will try later in a loop, because atomic read guarantees that half-way values will not be returned calling `load()` function. Or maybe first thread will try to write value later, allowing second thread to read value? – TwITe Oct 29 '18 at 11:31
  • When the CPU performs an atomic operation, it always ensures that the write+publish are performed atomically. – Daniel Trugman Oct 29 '18 at 11:39
  • I mean, `latest` is not simple to understand. if reader has done read operation first, it was the latest value for the `moment of reading`, even if writer wrote new value later. So, returned value to first thread will be latest value relatively to first thread, but it will not be latest value to second, writer thread. Am I right? – TwITe Oct 29 '18 at 11:39
  • Latest value is absolute. At the moment of reading, at that atomic time in the space-time-continuum, the value that is the most-up-to-date, is the one that the reader will ultimately see. – Daniel Trugman Oct 29 '18 at 11:45
1

if we declare atomic variable, do we always get the latest value of the variable calling load() operation?

Yes, for some definition of latest.

The problem with concurrency is that it is not possible to argue about order of events in the usual way. This comes from a fundamental limitation in the hardware where the only way to establish a global order of operations across multiple cores would be to serialize them (and eliminating all of the performance benefits of parallel computation in the process).

What modern processors provide instead is an opt-in mechanism to re-establish order between certain operations. Atomics are the language-level abstraction for that mechanism. Imagine a scenario in which two atomic<int>s a and b are shared between threads (and let's further assume they were initialized to 0):

// thread #1
a.store(1);
b.store(1);

// thread #2
while(b.load() == 0) { /* spin */ }
assert(a.load() == 1);

The assertion here is guaranteed to hold. Thread #2 will observe the "latest" value of a.

What the standard does not talk about is when exactly the loop will observe the value of b changing from 0 to 1. We know it will happen some time after the write by thread #1 and we also know it will happen after the write to a. But we don't know how long after.

This kind of reasoning is further complicated by the fact, that different threads are allowed to disagree when certain writes took place. If you switch to a weaker memory ordering, one thread may observe writes to distinct atomic variables happening in a different order than what is observed by another thread.

ComicSansMS
  • 46,689
  • 13
  • 143
  • 152