Date: Mon, 3 Jul 2000 20:00:39 +0930 From: Greg Lehey <grog@lemis.com> To: Daniel Eischen <eischen@vigrid.com> Cc: Jason Evans <jasone@canonware.com>, Luoqi Chen <luoqi@watermarkgroup.com>, smp@FreeBSD.ORG Subject: Re: SMP meeting summary Message-ID: <20000703200039.H62680@wantadilla.lemis.com> In-Reply-To: <Pine.SUN.3.91.1000703060948.5216A-100000@pcnet1.pcnet.com> References: <20000703114535.T39024@wantadilla.lemis.com> <Pine.SUN.3.91.1000703060948.5216A-100000@pcnet1.pcnet.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Monday, 3 July 2000 at 6:23:28 -0400, Daniel Eischen wrote: > On Mon, 3 Jul 2000, Greg Lehey wrote: >> On Monday, 26 June 2000 at 20:00:09 -0400, Daniel Eischen wrote: >>> Yes, this confirms what Jim Mauro said in the Solaris Internals course >>> at USENIX. Since mutexes are held only for very small amounts of time >>> and the kernel is sufficiently fine-grained, their was no advantage >>> to calling wake_one() as opposed to wake_all(). Obviously with these >>> semantics, the waiter with the highest priority should obtain the >>> mutex. At least that was my recollection... >> >> I find this rather strange. There can be many reasons to take a >> mutex, and not all of them have to be fast. Even in the case where >> they are, it doesn't seem to be of any value to wake more processes >> than can take the mutex. From >> http://www.sunworld.com/sunworldonline/swol-08-1999/swol-08-insidesolaris-2.html: >> >> Sun engineering coded the turnstile_wakeup() in Solaris 7 in a >> generic enough way so that a single thread wakeup could be >> executed, instead of all threads inevitably waking up >> together. Exhaustive testing under a variety of different loads has >> shown that, in practice, we very rarely end up with a large >> blocking chain of threads, and thus almost never run into the >> thundering herd problem. The wakeup-all implementation also solves >> some bit synchronization issues that make a wakeup-one scenario >> tricky. >> >> This seems like a less honest way of saying "We couldn't figure out >> how to avoid race conditions on wakeup, and so far nobody has been >> able to point to a thundering herd". I'd need some conviction. > > Well if you are considering spinning for a bit of time on a held > mutex (which you seem to advocate?), then why not wake everyone? Because it doesn't buy us anything. > If mutexes are held for very short periods of time and you don't > often have a thundering herd problem, That's an assumption. So far we have *never* had a thundering herd, because the code don't work yet. > then waking everyone is an optimization since you only have to take > the scheduling lock once. No. If I understand things correctly, each process would need to get the schedlock, and only one process can get the mutex. Why wake the rest? What do you want them to do? This applies even in the case of a counting semaphore (of which our "mutex" is a special case), since if any slots are available, the process wouldn't be sleeping. Greg -- Finger grog@lemis.com for PGP public key See complete headers for address and phone numbers To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20000703200039.H62680>