> > 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.
You will get scheduler-related results even from a simpler example
(which is equivalent to Konstantin's original program):
initially COND = 0
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);
f. COND = 3; 5. pthread_mutex_lock(mutex);
6. COND = 4;
7. pthread_mutex_unlock(mutex);
(Assuming the wait happens before the signal, so the signal is not lost).
State changes to COND are:
initially COND is New
After (b) COND is Excl(Thread1)
After (2) COND is ShM({Thread1,Thread2},{mutex})
After (3) signals at (c), COND is Excl(Thread1) as per proposed rule
Now if f happens before 5/6/7:
After (f) COND is Excl(Thread1)
After (5/6/7) COND is ShM({Thread1,Thread2},{mutex}), and no error
But if 5/6/7 happens before f:
After (5/6/7) COND is ShM({Thread1,Thread2},{mutex})
After (f) COND is ShM({Thread1,Thread2},{}) -- error
Without the proposed rule, the error is detected regardless of the
scheduling.
Such a rule can easily enough be installed in Helgrind. But you can't
have it both ways:
If the rule is installed, effectively you are promising that after the
signal from Thread 2 to Thread 1, Thread 2 will not access COND again
until Thread 1 first signals back at Thread 2. That makes Helgrind shut
up, but you lose some ability of Helgrind to report errors resulting
from later violations of the promise, depending on the scheduling.
If the rule is not installed, then Helgrind complains, but it can
at least check what happens next, independent of scheduling.
J
-------------------------------------------------------------------------
SF.Net email is sponsored by:
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
_______________________________________________
Valgrind-developers mailing list
Valgrind-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-developers
