[codahale]

If you want your reads to ever work, then they need to be synchronized. Reading from an unfenced address during concurrent writes is undefined behavior for any CPU architecture you can think of, which means you’ll get stale reads _in a best-case scenario_. You can also get garbage reads (e.g. as your CPU interprets your read of a 64-bit pointer as two 32-bit reads), crashes, bees, etc.

The code you write is either thread-safe, used in a single-threaded context, or a pinless grenade.

[pcwalton]

There are exceptions to this rule--i.e. there are ways to not really be thread-safe but to have things work anyway--but they fall in the category of "you have to really, really know your CPU and be willing to write processor-specific code that just happens to work", so you can basically ignore them.

My favorite is the libdispatch abuse of cpuid to flood the pipeline on Intel CPUs for this problem: https://www.mikeash.com/pyblog/friday-qa-2014-06-06-secrets-...

But really, take Coda's advice. If you aren't synchronizing your reads, you can basically just assume your code is broken.

[twic]

An interesting exception is Lamport's Bakery:

https://en.m.wikipedia.org/wiki/Lamport%27s_bakery_algorithm

Thread safety without synchronisation primitives. I'm not sure it's ever actually a good idea to use it, though.

EDIT: unless you count a fence as a synchronisation primitive.