[ltt-dev] [UST PATCH] Fix the once in a while freeze of the tests

[compudj@krystal.dyndns.org (Mathieu Desnoyers)]

* Yannick Brosseau (yannick.brosseau at gmail.com) wrote:
> On 2011-02-20 10:17, Mathieu Desnoyers wrote:
> > * Mathieu Desnoyers (compudj at krystal.dyndns.org) wrote:
> >   
> >> * Yannick Brosseau (yannick.brosseau at gmail.com) wrote:
> >>     
> >>> Sometimes, the thread in the read function would lock the pipe so the
> >>> setlinebuf would freeze on it. Set the linebuf before we create the
> >>> thread to fix this deadlock
> >>>       
> >> Can you update the description to show which locks are involved in this
> >> deadlock scenario ? E.g.
> >>
> >> - CPU A               - CPU B
> >>
> >> function              function
> >> lock A (taken)        lock B (taken)
> >> lock B (waiting)
> >>                       lock A (waiting)  <-- deadlock
> >>
> >> Or show it with the lock chain dependency analysis. But it's important
> >> to have this information along with this kind of fix.
> >>     
> > Hrm, ok I looked at tap.c, and it's not a deadlock at all: it's rather
> > that the _tap_comment_stdout thread can start using pipe_r_file when it
> > is still uninitialized.
> >
> >   
> I found a lock in the calls to fgets and setlinebuf, deep in the glibc.
> If what you says is true, the fix I've proposed is not right. Its the
> pthread_create that should be moved.
> 

I don't understand. It should only be the relative order of init vs
pthread_create (the user of this structure) that matters, no ?

Mathieu


-- 
Mathieu Desnoyers
Operating System Efficiency R&D Consultant
EfficiOS Inc.
http://www.efficios.com