public inbox for pthreads-win32@sourceware.org
 help / color / mirror / Atom feed
From: "Reddie, Steven" <Steven.Reddie@ca.com>
To: Alexander Terekhov <TEREKHOV@de.ibm.com>
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	[thread overview]
Message-ID: <A7E3A4B51615D511BCB6009027D0D18C06B3B919@aspams01.ca.com> (raw)

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" <Steven.Reddie@ca.com>@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 <Steven.Reddie@ca.com>
Development Leader - eTrust ETPKI
Computer Associates Pty Ltd (Australia)


             reply	other threads:[~2002-10-28  0:57 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-10-27 16:57 Reddie, Steven [this message]
2002-10-28  1:48 Alexander Terekhov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=A7E3A4B51615D511BCB6009027D0D18C06B3B919@aspams01.ca.com \
    --to=steven.reddie@ca.com \
    --cc=TEREKHOV@de.ibm.com \
    --cc=pthreads-win32@sources.redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).