From owner-cvs-all Wed Jul 4 9:48:27 2001 Delivered-To: cvs-all@freebsd.org Received: from mail5.speakeasy.net (mail5.speakeasy.net [216.254.0.205]) by hub.freebsd.org (Postfix) with SMTP id D0E9A37B40A for ; Wed, 4 Jul 2001 09:48:10 -0700 (PDT) (envelope-from jhb@FreeBSD.org) Received: (qmail 28868 invoked from network); 4 Jul 2001 16:48:09 -0000 Received: from unknown (HELO laptop.baldwin.cx) ([64.81.54.73]) (envelope-sender ) by mail5.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 4 Jul 2001 16:48:09 -0000 Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <20010703174807.R29024-100000@wonky.feral.com> Date: Wed, 04 Jul 2001 09:48:07 -0700 (PDT) From: John Baldwin To: Matthew Jacob Subject: Re: cvs commit: src/sys/sys systm.h condvar.h src/sys/kern kern_ Cc: cvs-all@FreeBSD.org, cvs-committers@FreeBSD.org, Jake Burkholder Sender: owner-cvs-all@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG 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 -- 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