Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 04 Jul 2001 09:48:07 -0700 (PDT)
From:      John Baldwin <jhb@FreeBSD.org>
To:        Matthew Jacob <mjacob@feral.com>
Cc:        cvs-all@FreeBSD.org, cvs-committers@FreeBSD.org, Jake Burkholder <jake@FreeBSD.org>
Subject:   Re: cvs commit: src/sys/sys systm.h condvar.h src/sys/kern kern_
Message-ID:  <XFMail.010704094807.jhb@FreeBSD.org>
In-Reply-To: <20010703174807.R29024-100000@wonky.feral.com>

next in thread | previous in thread | raw e-mail | index | archive | help

On 04-Jul-01 Matthew Jacob wrote:
> 
> 
> 
> On Tue, 3 Jul 2001, Jake Burkholder wrote:
> 
>> jake        2001/07/03 17:32:51 PDT
>>
>>   Modified files:
>>     sys/sys              systm.h condvar.h
>>     sys/kern             kern_synch.c kern_condvar.c
>>   Log:
>>   Implement mwakeup, mwakeup_one, cv_signal_drop and cv_broadcast_drop.
>>   These take an additional mutex argument, which is dropped before any
>>   processes are made runnable.  This can avoid contention on the mutex
>>   if the processes would immediately acquire it, and is done in such a
>>   way that wakeups will not be lost.
> 
> 
> I'm a bit confused by this last statement. Wakeups should never be lost
> not matter what.

If you released the lock before acquiring sched_lock in wakeup() there is a
window during which you can lose a wakeup.  Well, now that I play with this in
my head, I can't think of a wakeup being missed, but I can see the state of the
subsytem being altered by another CPU before the wakeup is delivered (since the
lock is unlocked and we may preempt on lock release and thus alter the state of
the locked subsytem before coming back to the original thread and doing the
wakeup) resulting in possibly bogus wakeups being sent.  Yuck.

> I can see that it's possible you could get contention if the cv_signal
> or wakeup causes a reschedule on another CPU right away. Is there any
> empirical measurements showing this happening?

If a CPU is idle this can easily happen.  In a fully preeemptive kernel where
wakeup (well, setrunqueue) will switch to the new process that it just woke up
if it is higher priority than the current one it can easily happen as well.
 
-- 

John Baldwin <jhb@FreeBSD.org> -- http://www.FreeBSD.org/~jhb/
PGP Key: http://www.baldwin.cx/~john/pgpkey.asc
"Power Users Use the Power to Serve!"  -  http://www.FreeBSD.org/

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe cvs-all" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?XFMail.010704094807.jhb>