A really great article. The concepts apply just the same for x86_64 as well. You need those memory barriers or std::atomics for the correct behavior, no matter what.
Another example that might be easier for people to understand is this (taken from Herb Sutter’s std::atomic<> weapons talk): if one thread does this:
bool g;
std::atomic<bool> a;
g = 1;
a = 1;
And the other thread does this:
if (a)
assert(g)
the assert must NEVER fail - that is, ALL writes performed by a thread must be visible to ALL other threads before the other threads see the “after” value of an atomic write. This is the same thing the author tries to explain in the article, but is a little simpler of an example.
Now, perhaps you don’t really need all of those writes to be visible, just the ones that relate to the atomic variable you’re writing to. Couldn’t that be a little cheaper? That’s when you start diving into the std::memory_order_consume rabbit hole :)
A really great article. The concepts apply just the same for x86_64 as well. You need those memory barriers or std::atomics for the correct behavior, no matter what.
Another example that might be easier for people to understand is this (taken from Herb Sutter’s std::atomic<> weapons talk): if one thread does this:
And the other thread does this:
the assert must NEVER fail - that is, ALL writes performed by a thread must be visible to ALL other threads before the other threads see the “after” value of an atomic write. This is the same thing the author tries to explain in the article, but is a little simpler of an example.
Now, perhaps you don’t really need all of those writes to be visible, just the ones that relate to the atomic variable you’re writing to. Couldn’t that be a little cheaper? That’s when you start diving into the
std::memory_order_consumerabbit hole :)