Re: Re: 1.5.25-15: pthread_join deadlocks
Corinna Vinschen wrote: On Nov 19 12:29, Ryan Johnson wrote: Hi all, I'm hitting a deadlock with cygwin pthreads when joining on a short-lived thread -- for me the second such thread creation will almost never return. It looks *exactly* like a problem that others noticed as far back as early 2005 [0], and from the output of strace on the test case (below) the culprit is almost certainly a racy optimization in __cygwin_lock_* for which a patch was submitted six months ago [1]. As of today my cygwin distribution is completely up to date. Any hope of an update coming out soon? The update will be Cygwin 1.7. You testcase works fine for me on Cygwin 1.7, so maybe you should try this path. See http://cygwin.com/#beta-test Ah, that's good to know. I'll try it out when I get a few minutes. Meanwhile, firing up an extra thread at program start, and having it just block on a cond var nobody will ever signal, seems to avoid the problem completely. Out of curiosity, how much did removing the racy optimization hurt performance? The patch just yanked it completely iirc. An alternative might be to have the main thread check for single-thread environment only at acquire time, and then release only if it acquired (the latter is probably a good idea regardles...). Thanks, Ryan -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: 1.5.25-15: pthread_join deadlocks
Ryan Johnson wrote: Out of curiosity, how much did removing the racy optimization hurt performance? The patch just yanked it completely iirc. An alternative might be to have the main thread check for single-thread environment only at acquire time, and then release only if it acquired (the latter is probably a good idea regardles...). The problem is, IIRC there is no such thing as a single-thread environment for cygwin programs: every cygwin program has a secondary thread that handles translating certain windows events into unixy signals, or something like that. I think. -- Chuck -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: 1.5.25-15: pthread_join deadlocks
On Fri, Nov 20, 2009 at 09:01:00AM -0500, Charles Wilson wrote: Ryan Johnson wrote: Out of curiosity, how much did removing the racy optimization hurt performance? The patch just yanked it completely iirc. An alternative might be to have the main thread check for single-thread environment only at acquire time, and then release only if it acquired (the latter is probably a good idea regardles...). The problem is, IIRC there is no such thing as a single-thread environment for cygwin programs: every cygwin program has a secondary thread that handles translating certain windows events into unixy signals, or something like that. I think. Yes, there's at least one extra thread active in every cygwin program. If you've used select() at any point there will be more. cgf -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
