Date: Mon, 3 Jul 2000 11:45:35 +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: <20000703114535.T39024@wantadilla.lemis.com> In-Reply-To: <Pine.SUN.3.91.1000626193709.15096A-100000@pcnet1.pcnet.com> References: <20000626151441.L8965@blitz.canonware.com> <Pine.SUN.3.91.1000626193709.15096A-100000@pcnet1.pcnet.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Monday, 26 June 2000 at 20:00:09 -0400, Daniel Eischen wrote: > On 26 Jun 2000, Jason Evans wrote: > >> On Mon, Jun 26, 2000 at 02:49:57PM -0700, Jason Evans wrote: >>> On Mon, Jun 26, 2000 at 04:13:24PM -0400, Luoqi Chen wrote: >>>>> Processes that block on a mutex are granted the lock in FIFO order, rather >>>>> than priority order. In order to avoid priority inversion, the mutex wait >>>>> queue implements priority lending. >>>>> >>>> Ok. I remember I have read somewhere that solaris 7 has given up the behavior >>>> of waking up only one thread after a mutex is released, now it wakes up all >>>> the blocking threads. It seems that the "thundering herd" problem is not >>>> serious after all if the lock granuity is high enough. >>> >>> I don't think this is the case. >> >> Whoops. The article is broken into two web pages, and the second page >> states exactly what you said: as of Solaris 7, all waiting threads are >> woken up. > > 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. 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?20000703114535.T39024>