From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9291 invoked by alias); 28 Oct 2002 00:57:25 -0000 Mailing-List: contact pthreads-win32-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: pthreads-win32-owner@sources.redhat.com Received: (qmail 9243 invoked from network); 28 Oct 2002 00:57:23 -0000 Received: from unknown (HELO aspams52.ca.com) (155.35.248.76) by sources.redhat.com with SMTP; 28 Oct 2002 00:57:23 -0000 Received: by aspams52.ca.com with Internet Mail Service (5.5.2656.59) id ; Mon, 28 Oct 2002 11:57:25 +1100 Message-ID: From: "Reddie, Steven" To: Alexander Terekhov Cc: pthreads-win32@sources.redhat.com Subject: RE: Why does cond_signal not block until a waiter is woken like c ond_ broadcast does? Date: Sun, 27 Oct 2002 16:57:00 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-SW-Source: 2002/txt/msg00107.txt.bz2 Hmm, maybe it's not a matter of "since when" but "until when". It looks like much has changed since we last took a snapshot (it's been working fine, so why update?). Our source has a condvar.c but I see that even in the Attic this module has been split into several. In our module, the broadcaster waits for the last woken waiter to set an event signalling that all waiters have finished. It looks like this is no longer the case. Sorry for the noise. Regards, Steven -----Original Message----- From: Alexander Terekhov [mailto:TEREKHOV@de.ibm.com] Sent: Saturday, 26 October 2002 7:05 AM To: Reddie, Steven Cc: pthreads-win32@sources.redhat.com Subject: Re: Why does cond_signal not block until a waiter is woken like cond_ broadcast does? Steven Reddie wrote: [...] > pthread_cond_broadcast doesn't return until all waiters have woken. Uhmm. Since when? Well, looking at the CVS stuff available here: http://sources.redhat.com/cgi-bin/cvsweb.cgi/pthreads/pthread_cond_signal.c? rev=1.1&content-type=text/x-cvsweb-markup&cvsroot=pthreads-win32 I just fail to understand what do you mean saying "pthread_cond_broadcast doesn't return until all waiters have woken". Perhaps you can clarify it a little bit. > Also, I can't determine from the POSIX docs if pthread_cond_broadcast must > be implemented in such a way that it blocks until all waiters have woken. I > assume this means it isn't specified, but if anyone knows please let me > know. Well, A) http://www.opengroup.org/onlinepubs/007904975/functions/pthread_cond_signal. html (don't miss "RATIONALE" bits) B) http://www.linux.org.uk/~ajh/ols2002_proceedings.pdf.gz (Acrobat: "479 of 631", read on "futexes") C) Consider the following stuff that might help you [as usual, modulo bugs and any thing(s) that I've myself missed and/ or misunderstood] understand how it is all meant to work. http://www.terekhov.de/DESIGN-futex-CV.txt http://www.terekhov.de/DESIGN-futex-CV.cpp regards, alexander. "Reddie, Steven" @sources.redhat.com on 10/25/2002 08:43:05 AM Sent by: pthreads-win32-owner@sources.redhat.com To: pthreads-win32@sources.redhat.com cc: Subject: Why does cond_signal not block until a waiter is woken like cond_ broadcast does? Hi, I don't think I've found a bug but am just wondering about the behaviour of the condition variables. pthread_cond_broadcast doesn't return until all waiters have woken. This would seem to stop any new waiters from grabbing the semaphore meant for an existing waiter, since the mutex is held for the duration of pthread_cond_broadcast. This would also seem to stop any subsequent broadcast or signal calls from other threads while the first is in progress. If pthread_cond_broadcast returned before the waiters have all woken up then further logic would be needed to both stop further broadcasts from interfering with the current one, and to stop new waiters from waking on the current broadcast thereby starving an existing waiter. I think I've figured out the required code changes, but I don't know if this is desireable behaviour. However, pthread_cond_signal does not do this, it simply increments the semaphore count and immediately returns. This makes me think that there is a potential problem if a few signal calls are followed by a broadcast call without any of the waiting threads waking in between. To illustrate: * threads 1-5: all waiting on the same condition variable (waiters now = 5) * thread 0: pthread_cond_signal (semaphore incremented to 1, waiters still = 5) * thread 0: pthread_cond_signal (semaphore incremented to 2, waiters still = 5) * thread 0: pthread_cond_signal (semaphore incremented to 3, waiters still = 5) * thread 0: pthread_cond_broadcast (waiters = 5, so sempahore is incremented by 5, to 8) If this is what happens then this would result in a deadlock, because no more waiters can be added while cond_broadcast holds the lock, but until a further 3 waiters come along the cond_broadcast call cannot complete. Surely I'm missing something, but please let me know either way. Also, I can't determine from the POSIX docs if pthread_cond_broadcast must be implemented in such a way that it blocks until all waiters have woken. I assume this means it isn't specified, but if anyone knows please let me know. Regards, Steven -- Steven Reddie Development Leader - eTrust ETPKI Computer Associates Pty Ltd (Australia)