Re: [Valgrind-users] Producer consumer race problem

[Julian S. <js...@ac...>]

> Indeed, I think the same: I can not see any situation of race in the
> program (and testing seems to agree with me); still, valgrind-3.3.1
> complains. Maybe there was a bug there, already fixed on trunk.

Helgrind in 3.3.1 uses an algorithm which sometimes incorrectly reports
races, which I think is what happened here.  (These limitations are
documented in the Helgrind 3.3.1 manual).   Helgrind in the trunk uses
a less aggressive algorithm, which (correctly) reports no races, but the
tradeoff is that the less aggressive algorithm can sometimes miss real
races.  It's a difficult problem.

> Let's try writing a "proof":

Note that there are 2 different questions here:

* is your code correct (race-free) ?

* is Helgrind-trunk correct to report zero races in your code?

I think the answer to both is "yes", but I was mainly concerned with
the second question :-)

To clarify what exactly Helgrind-trunk is checking:

Helgrind-trunk reports a race when on a location, when it sees accesses
from two different threads to the location, at least one of which is a 
write, but it does not see any synchronisation operation between the
two threads.  Since no synchronisation operation is observed, it could
be that the accesses happen in a different order in a different run 
of the program (based on relative speeds of the threads).  Hence it reports
a race.

buffer_t::in is guarded by buffer_t::mutex_in.  Accesses by different
threads to buffer_t::in are all separated by a synchronisation operation,
which is: unlock of mutex_in followed by lock of mutex_in.  Hence no
reported race.

Same logic applies for buffer_t::out.

For the elements in buffer_t::buffer itself, the synchronisation operation
(inter-thread dependency) is created by the post->wait pair on ::data
(for the reader to be able to proceed) and the post->wait pair on ::free
(for the writer to be able to proceed).

Anyway, that doesn't prove or disprove anything about your code.  But
it might give you a bit better insight into what Helgrind-trunk and
also Drd-trunk are really checking.

J