Am Mittwoch, 5. Dezember 2007 schrieb Julian Seward:
> 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
> shared-modified to exclusively-owned-by-parent at the point of the
> signal/wait pair?

Currently I think that one does not change the state of the variable. But when 
one detects an error with the current approach, one would check the 
happens-before graph to see whether there really is a problem.

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

There is one problem when several signals are emitted. Which one should one 
use to establish the happens-before relation? This could make the tool 
dependent on the scheduler. For example the following code:

Thread 1:                            Thread 2:

a. pthread_mutex_lock(mutex);        1.   pthread_mutex_lock(mutex);
b. while (COND != 1) {               2.   COND = 1;
c.    pthread_cond_wait(cv);         3.   pthread_cond_signal(cv);
d. }                                 4.   pthread_mutex_unlock(mutex);
e. pthread_mutex_unlock(mutex);      5.   pthread_mutex_lock(mutex);
f. COND = 3;                         6.   COND = 2;
                                     7.   pthread_cond_signal(cv);
                                     8.   pthread_mutex_unlock(mutex);

If thread 1 wakes up on the first signal in line 3, then there is a problem in 
lines f and 6. If thread 1 wakes up on the second signal in line 7, one would 
not detect an error. Detecting the error in the first case would be the hard 
case in my opinion.

...
> Instead of using source annotations, you can also avoid this
> 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
> CVs.

You are right. But lots of code uses condition variables. I would like to use 
helgrind on several code parts that use condition variables, but currently 
the false positive count is too high.

-------------------------------------------------------------------------
SF.Net email is sponsored by: The Future of Linux Business White Paper
from Novell.  From the desktop to the data center, Linux is going
mainstream.  Let it simplify your IT future.
http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
_______________________________________________
Valgrind-developers mailing list
Valgrind-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-developers

Reply via email to