|
Re: [Valgrind-users] [Valgrind-developers] false positive in
helgrind with cond_wait/cond_signal (?)
From: Christoph B. <bar...@or...> - 2007-12-05 15:32:33
|
Am Mittwoch, 5. Dezember 2007 schrieb Julian Seward:
> > COND is accessed before cond_signal() in child thread
>
> yes
>
> > and after cond_wait() in parent thread.
>
> no:
>
> while (COND !=3D 1) {
> fprintf(stderr, "Wait: COND: %d\n", COND);
> pthread_cond_wait(&CV, &MU);
> }
>
> If the parent only accessed COND after cond_wait, then Helgrind would
> not complain, as then it would understand that "exclusive ownership" is
> transferred from child to parent by the signal/wait pair. However, both
> parent and child access it before the signal/wait pair, COND is marked
> as being in shared ownership, and the above doesn't apply.
I do not know how helgrind evaluates the happens-before relation to lower i=
ts=20
false positives rate, but is it not possible to apply it here too?
The read of COND in the parent thread happens in a segment that is after th=
e=20
accesses that established the shared-modified state in the happens-before=20
graph.
Given that COND should not trigger an error.
To establish the happens-before relation one needs a=20
VALGRIND_HG_POST_WAIT(&CV) client-request as it is described in Arndt=20
M=FChlenfeld's PhD thesis, because one cannot know whether the code calls=20
pthread_cond_wait at all.
Christoph
|
|
Re: [Valgrind-users] [Valgrind-developers] false positive in
helgrind with cond_wait/cond_signal (?)
From: Julian S. <js...@ac...> - 2007-12-05 16:08:49
|
On Wednesday 05 December 2007 16:32, Christoph Bartoschek wrote: > The read of COND in the parent thread happens in a segment that is after > the accesses that established the shared-modified state in the > happens-before graph. > > Given that COND should not trigger an error. But why should we assume that ownership of COND should change from=20 shared-modified to exclusively-owned-by-parent at the point of the signal/wait pair? In this example, it would cause Helgrind to shut up, but it's not obvious to me that this is a good thing to do in general. It would be easy enough (although expensive) to modify Helgrind so that, when thread X signals at Y, memory shared by X and Y is made exclusive to Y. Is that helpful or correct? I don't know. I don't know what the consequences would be, just now. > To establish the happens-before relation one needs a > VALGRIND_HG_POST_WAIT(&CV) client-request as it is described in Arndt > M=FChlenfeld's PhD thesis, because one cannot know whether the code calls > pthread_cond_wait at all. That's an orthogonal issue. What you say is true in the general case. But for this example, the presence of sleep(2) and the assumption that the parent will not be=20 delayed > 2 seconds before entering its while loop, ensures the signal/wait call really happens, so the dependency is not lost, as described by Muehlenfeld. Instead of using source annotations, you can also avoid this=20 missing-dependency problem with CVs by using semaphores instead. Helgrind tracks dependencies through semaphores exactly. A semaphore with an initial value of zero is useful for signalling events between threads, without having to mess with these boolean conditions on=20 CVs. J |