Question

Here, in this example, I’m assuming that we’re on a X86 system with at least two physical cores and thread #1 and #2 is running on it’s own CPU core (true parallelism):

[initial state]
shared_memory_location = 0;

[thread #1]
shared_memory_location = 1;
signal();

[thread #2]
wait_for_signal();
print(shared_memory_location);

What’s the value of shared_memory_location on thread #2?

This is my take on this: It could have been either 0 or 1 but the consistency model of X86 ensures that any read after a memory location write will read the new value regardless of which CPU core this read is occurring on.

The X86 consistency model will ensure that the second physical core executing thread #2 doesn’t pick up an invalid value from the CPU core private cache. X86 makes this a lot easier but there’s no guarantees that any other system such as ARM will behave in this way.

If you didn’t have the consistency model of X86 how would you ensure that thread #2 was able to read the new value when it is signaled from thread #1?

…or more to the point, how do you hand of a value to a thread which is waiting on a signal in a correct manner?

DISCLAIMER: I could be completely wrong about the X86 consistency model, please correct me if I am!

Answer 1

If the signal() and wait_for_signal() methods calls memory barrier internally, then the scenario you describe will not occurs even on ARM, because of the memory barrier call flushes the data to the main memory instead of private core cache, i.e at the signal method it will flushes the data to main memory, so the shared_memory_location will be “volatile write”, and it will also flushes the data to to the main memory after the wait_for_signal, so reading shared_memory_location will be “volatile read”.