From mboxrd@z Thu Jan 1 00:00:00 1970 From: compudj@krystal.dyndns.org (Mathieu Desnoyers) Date: Sun, 20 Feb 2011 13:40:58 -0500 Subject: [ltt-dev] [UST PATCH] Fix the once in a while freeze of the tests In-Reply-To: <4D613705.5000502@gmail.com> References: <1298065013-9872-1-git-send-email-yannick.brosseau@gmail.com> <4D613705.5000502@gmail.com> Message-ID: * 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