On 9 March 2014 19:45, Niall Douglas wrote:
On 9 Mar 2014 at 10:31, Jonathan Wakely wrote:
Can tsan understand when an atomic is being used for serialisation? I can see a CAS lock being heuristically determined, but some of the fancier semaphore based techniques surely need some explicit markup.
I believe it can, because it knows that an atomic store with memory_order_release in one thread and a load with memory_order_acquire in another thread implies an ordering, and so can tell there is no race.
The reason I'm suspicious this is the case is because valgrind doesn't do this, yet it certainly can tell atomic ops from non-atomic ones (besides, on x86/64 loads always acquire and stores always release anyway).
That's exactly why valgrind can't tell atomic ops from non-atomic ones (on x86_64). Valgrind just sees the instructions, it doesn't know the context that generated the instruction.
I can see maybe that the compiler knows things that valgrind cannot, but I guess we're probably speculating now.
Of course the compiler knows things valgrind cannot. If the source code has a compiler intrinsic for an atomic op then tsan knows the compiler is prevented from moving things across the operation and knows the generated instruction is being used specifically as an atomic op, not just a plain load or store, and can tag/instrument/whatever that the operation will not result in a data race (even though it might use exactly the same insn as another load/store that might result in a race).