Date: Mon, 3 Jul 2000 06:23:28 -0400 (EDT) From: Daniel Eischen <eischen@vigrid.com> To: Greg Lehey <grog@lemis.com> Cc: Jason Evans <jasone@canonware.com>, Luoqi Chen <luoqi@watermarkgroup.com>, smp@FreeBSD.ORG Subject: Re: SMP meeting summary Message-ID: <Pine.SUN.3.91.1000703060948.5216A-100000@pcnet1.pcnet.com> In-Reply-To: <20000703114535.T39024@wantadilla.lemis.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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? If mutexes are held for very short periods of time and you don't often have a thundering herd problem, then waking everyone is an optimization since you only have to take the scheduling lock once. If mutexes can be held for long periods of time, then you probably wouldn't want to wake everyone. -- Dan Eischen 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?Pine.SUN.3.91.1000703060948.5216A-100000>