Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner@cygwin.com Mail-Followup-To: cygwin@cygwin.com Delivered-To: mailing list cygwin@cygwin.com Subject: RE: pthread_cond_wait does not relock mutex on release MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 17 Apr 2002 17:21:37 +1000 Message-ID: X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: From: "Robert Collins" To: "Michael Labhard" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by delorie.com id g3H7M2100382 > -----Original Message----- > From: Michael Labhard [mailto:ince@pacifier.com] > Sent: Wednesday, April 17, 2002 5:01 AM > To: cygwin@cygwin.com > Subject: pthread_cond_wait does not relock mutex on release > > > Don't no if anyone else has noticed this: the > pthread_cond_wait when signalled does not lock the associated > mutex again. This is incorrect. It does lock the mutex again.: (from __pthread_cond_dowait which implemented pthread_cond_wait) (*themutex)->Lock (); if (last == true) (*cond)->mutex = NULL; if (pthread_mutex_lock (&(*cond)->cond_access)) system_printf ("Failed to lock condition variable access mutex, this %p", *c ond); InterlockedDecrement (&((*themutex)->condwaits)); if (pthread_mutex_unlock (&(*cond)->cond_access)) system_printf ("Failed to unlock condition variable access mutex, this %p", *cond); return rv; } Chances are your test app is buggy, or you are making one or more assumptions about the mutex type (ie recursiveness etc) that are incorrect. Rob -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/