On Dec 5, 2007 2:24 PM, Julian Seward <[EMAIL PROTECTED]> wrote:
>
> > COND is accessed before cond_signal() in child thread
>
> yes
>
> > and after cond_wait() in parent thread.
>
> no:
>
> while (COND != 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.
Yes, COND *is* accessed before cond_wait() by the parent thread -- it the
condition of the cond_wait's while loop :)
Therefore, I agree, it is ShMod by both threads with nonempty lockset.
But once we did signal/wait we only access COND in the parent thread.
why can't we transfer ShMod->Exclusive after cond_signal/cond_wait().
More generally if a thread #x does cond_signal and thread #y does cond_wait
we transfer ShMod(#x, #y, #z) -> ShMod(#y, #z).
Will we loose any true positives with such logic?
>
>
> > >> If you change the order of these two lines, to
> >
> > Sure. But thread_join is not what is usually done in presence of thread
> > pools...
> > Threads tend to live forever.
> > This program is just a short reproducer.
>
> Yes. I suspect what you are seeing is a problem to do with memory
> recycling. See Helgrind manual Sec 7.5 point 2.
I did put VALGRIND_HG_CLEAN_MEMORY everywhere I could find :)
I don't think this is it.
>
>
> Can you send a slightly bigger reproducer, which has the child thread
> doing a few units of work that are passed to it from the parent thread?
>
I should (and will) certainly do this, but it's rather hard...
We have our own mutexes and our own thread pool with callback machinery.
The point is that we usually call thread_join at the very end of the program
and helgrind's logic related to thread_join does not kick in.
As I understand, _VG_USERREQ__HG_PTHREAD_JOIN_POST will work only if the
thread actually did quit.
Do you think it is possible to implement a similar request to indicate the
end of ThreadPool's callback?
Again, I'll try to come back with a reproducer.
>
> J
>
-------------------------------------------------------------------------
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
