On Wed, Sep 10, 2003 at 03:07:21PM +0100, Philip Martin wrote:
> mark benedetto king <mbk@lowlatency.com> writes:
>
> > On Wed, Sep 10, 2003 at 08:29:39AM -0400, mark benedetto king wrote:
> >
> > wait(cond,mutex):
> > acquire(cond->mutex)
> > cond->num_waiters++
> > release(cond->mutex)
> > release(mutex)
> > down(cond->sem)
> > up(cond->ack)
> > acquire(mutex)
> >
> > deliver(cond,count):
> > up(cond->sem, count)
> > down(cond->ack, count)
> > count->num_waiters -= count
> >
> > signal(cond):
> > acquire(cond->mutex)
> > deliver(cond, min(1, cond->num_waiters))
> > release(cond->mutex)
> >
> > broadcast(cond):
> > acquire(cond->mutex)
> > deliver(cond, cond->num_waiters);
> > release(cond->mutex)
>
> I am not familiar with the sematics of the Win32 "counting
> semaphores", your up/down in the algorithm above, but that algorithm
A binary semaphore has a single binary value, we'll call it "avail".
This is a spin-lock implementation:
down(s):
while 1:
acquire(s->mutex)
if s->avail:
s->avail = 0;
release(s->mutex)
return
release(s->mutex)
up(s):
acquire(s->mutex)
s->avail = 1;
release(s->mutex)
A counting semaphore keeps an internal counter; we'll call it num_avail.
This is a spin-lock implementation:
down(s, n):
while 1:
acquire(s->mutex)
if s->avail >= n:
s->avail -= n;
release(s->mutex)
return
release(s->mutex)
up(s,n):
acquire(s->mutex)
s->avail += n
release(s->mutex)
> doesn't look right. What behaviour you are trying to achieve, are you
> after the POSIX behaviour where broadcast wakes every waiting thread?
> What about this scenario
Yes. I accomplish that by delivering N signals, where N is the number
of waiters.
> thread 1 waits
> thread 2 waits
> thread 3 broadcasts
> thread 1 wakes up and runs
> thread 1 waits again
Because thread 3 is still holding cond->mutex, thread 1 cannot
actually wait until the broadcast is complete. Broadcast and signal
do not release cond->mutex until all waiters have been woken up.
Once thread 2 wakes and calls up(cond->ack, 1), the down() in deliver
(called from broadcast) will return, and thread 3 will release
cond->mutex. At this point, thread 1 will be allowed to wait.
--ben
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Sep 10 16:20:56 2003