Re: [Valgrind-users] Producer consumer race problem

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

On Tuesday 09 December 2008, Bart Van Assche wrote:
> In my opinion the following Helgrind-trunk behavior is incorrect:
> * Helgrind-trunk does not complain on any access of buffer_t::in,
> buffer_t::out or buffer_t::buffer.

As far as I can see, buffer_t::in is only accessed when
buffer_t::mutex_in is held.  So that looks safe to me.
Similarly, buffer_t::out is only accessed when buffer_t::mutex_out 
is held.

It's harder to make an argument of why there is no race on buffer_t::buffer.
That's really something that Miguel should be able to tell us.
My guess is as follows:

Firstly, can the writer (buffer_send) wrap around and overtake the
reader (buffer_recv) ?  I don't think so, because buffer_t::free, 
which is initialised to BUFFER_MAX, will block the writer after
BUFFER_MAX writes without a read.  Dually buffer_t::data, which
is initialised to zero, stops the reader overtaking the writer.

So with these two semaphores, we are guaranteed that each element
in buffer is strictly: written, read, written, read, etc.

After each write the writer posts to buffer_t::data; only then can
the reader read it.  ==> no race there.

After each read, the reader posts to buffer_t::free; only then can
the writer put a new value in that slot.  ==> no race there.

So (assuming the above is correct!) I think there really is no race,
and Helgrind-trunk is correct not to complain.


> * Helgrind-trunk complains on pthread_exit(). If you want to know why
> drd-trunk doesn't complain on pthread_exit(), see also
> http://article.gmane.org/gmane.comp.debugging.valgrind.devel/3326

Ah yes, I had forgotten about that page-at-the-top-of-the-stack stuff.

J