Date: Mon, 3 Jul 2000 18:35:55 -0500 (CDT) From: David Scheidt <dscheidt@enteract.com> To: Greg Lehey <grog@lemis.com> Cc: "Jeroen C. van Gelderen" <jeroen@vangelderen.org>, Daniel Eischen <eischen@vigrid.com>, Jason Evans <jasone@canonware.com>, Luoqi Chen <luoqi@watermarkgroup.com>, smp@FreeBSD.ORG Subject: Re: SMP meeting summary Message-ID: <Pine.NEB.3.96.1000703182157.14851A-100000@shell-2.enteract.com> In-Reply-To: <20000704083822.A65029@wantadilla.lemis.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 4 Jul 2000, Greg Lehey wrote: : :There's nothing to say that wake_one is more complex. wake_one takes :the first process on the mutex's sleep list and wakes it. wake_all :(or whatever) would make a loop out of that wake function and wake all :the processes on the list. All would then be scheduled, try to take :the mutex, and all except one would fail and be put back on the sleep :list. Does this make sense? With a wake_one function, you need to be much more careful to avoid priority inversion, and all sorts of other potential races. Solaris's locks are very fine grained, and it wouldn't suprise me at all if their average case was to wake only one process. Under that case, you get a wake_all that performs very much like wake_one, and you get to avoid the overhead of having to sort a sleep queue, or the like. There may be a slight performance penality, but a whole class of deadlock is removed, which makes it easier to produce correct code. In many cases, I'll take a performance hit for availability. It's quite likely, perhaps even certain, that FreeBSD isn't going to be a position where the sleep queues average length is close enough to one for this to be a viable approch in the medium-term. (I haven't had a chance to thourghly understand what the SMP road map looks like) If that is the case, then wake_one would be a win for FreeBSD. David Scheidt 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.NEB.3.96.1000703182157.14851A-100000>