| From | Sent On | Attachments |
|---|---|---|
| Jason Evans | Jun 24, 2000 11:56 pm | |
| Daniel Eischen | Jun 25, 2000 6:58 am | |
| Terry Lambert | Jun 25, 2000 10:12 am | |
| Terry Lambert | Jun 25, 2000 10:36 am | |
| Julian Elischer | Jun 25, 2000 10:41 am | |
| Poul-Henning Kamp | Jun 25, 2000 11:07 am | |
| Nate Williams | Jun 25, 2000 9:41 pm | |
| Frank Mayhar | Jun 25, 2000 11:27 pm | |
| Frank Mayhar | Jun 25, 2000 11:31 pm | |
| Luoqi Chen | Jun 26, 2000 9:46 am | |
| Arun Sharma | Jun 26, 2000 9:47 am | |
| Jason Evans | Jun 26, 2000 11:06 am | |
| Matthew Dillon | Jun 26, 2000 12:26 pm | |
| Matthew Dillon | Jun 26, 2000 12:48 pm | |
| John Sconiers | Jun 26, 2000 12:56 pm | |
| Matthew Dillon | Jun 26, 2000 1:07 pm | |
| Luoqi Chen | Jun 26, 2000 1:13 pm | |
| Doug Rabson | Jun 26, 2000 1:26 pm | |
| Jason Evans | Jun 26, 2000 2:56 pm | |
| Jason Evans | Jun 26, 2000 3:14 pm | |
| Daniel Eischen | Jun 26, 2000 4:59 pm | |
| Luoqi Chen | Jun 26, 2000 7:14 pm | |
| Jason Evans | Jun 26, 2000 7:55 pm | |
| Joe Eykholt | Jun 26, 2000 8:09 pm | |
| Greg Lehey | Jun 27, 2000 8:00 pm | |
| Jason Evans | Jun 27, 2000 8:25 pm | |
| Daniel Eischen | Jun 27, 2000 8:26 pm | |
| Greg Lehey | Jun 27, 2000 9:59 pm | |
| Greg Lehey | Jun 27, 2000 10:11 pm | |
| Terry Lambert | Jun 28, 2000 4:15 pm | |
| Terry Lambert | Jun 28, 2000 4:18 pm | |
| Terry Lambert | Jun 28, 2000 4:37 pm | |
| Terry Lambert | Jun 28, 2000 4:51 pm | |
| Arun Sharma | Jun 28, 2000 9:43 pm | |
| Greg Lehey | Jul 2, 2000 7:15 pm | |
| Daniel Eischen | Jul 3, 2000 3:23 am | |
| Greg Lehey | Jul 3, 2000 3:30 am | |
| Jeroen C. van Gelderen | Jul 3, 2000 7:55 am | |
| Chuck Paterson | Jul 3, 2000 8:28 am | |
| Chuck Paterson | Jul 3, 2000 8:47 am | |
| Frank Mayhar | Jul 3, 2000 8:49 am | |
| Greg Lehey | Jul 3, 2000 4:08 pm | |
| David Scheidt | Jul 3, 2000 4:35 pm | |
| Joe Eykholt | Jul 3, 2000 4:47 pm | |
| Greg Lehey | Jul 3, 2000 4:52 pm | |
| Joe Eykholt | Jul 3, 2000 4:58 pm | |
| Greg Lehey | Jul 3, 2000 5:26 pm | |
| Joe Eykholt | Jul 3, 2000 5:41 pm | |
| Chuck Paterson | Jul 3, 2000 7:17 pm | |
| Daniel Eischen | Jul 3, 2000 7:25 pm | |
| Daniel Eischen | Jul 3, 2000 7:35 pm | |
| Greg Lehey | Jul 3, 2000 7:39 pm | |
| Daniel Eischen | Jul 3, 2000 7:41 pm | |
| Chuck Paterson | Jul 3, 2000 8:40 pm | |
| Alfred Perlstein | Jul 3, 2000 10:08 pm | |
| Greg Lehey | Jul 3, 2000 10:37 pm | |
| Peter Wemm | Jul 4, 2000 2:43 pm | |
| Greg Lehey | Jul 4, 2000 3:58 pm | |
| Peter Wemm | Jul 4, 2000 4:06 pm | |
| Terry Lambert | Jul 5, 2000 3:38 pm | |
| Terry Lambert | Jul 5, 2000 4:00 pm | |
| Terry Lambert | Jul 5, 2000 4:06 pm | |
| Terry Lambert | Jul 5, 2000 4:10 pm | |
| Alfred Perlstein | Jul 5, 2000 4:29 pm | |
| Terry Lambert | Jul 6, 2000 4:50 pm |
| Subject: | Re: SMP meeting summary | |
|---|---|---|
| From: | Greg Lehey (gr...@lemis.com) | |
| Date: | Jul 2, 2000 7:15:13 pm | |
| List: | org.freebsd.freebsd-smp | |
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 gr...@lemis.com for PGP public key See complete headers for address and phone numbers
To Unsubscribe: send mail to majo...@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message





