Re: [boost] [thread] Address sanitizer failures on marshall-mac

Subject: Re: [boost] [thread] Address sanitizer failures on marshall-mac
From: Jonathan Wakely (jwakely.boost_at_[hidden])
Date: 2014-03-09 16:20:38

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).