Date: Tue, 4 Jul 2000 09:22:45 +0930 From: Greg Lehey <grog@lemis.com> To: Chuck Paterson <cp@bsdi.com> Cc: 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: <20000704092245.B65029@wantadilla.lemis.com> In-Reply-To: <200007031528.JAA26798@berserker.bsdi.com> References: <200007031528.JAA26798@berserker.bsdi.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Monday, 3 July 2000 at 9:28:34 -0600, Chuck Paterson wrote: >> 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 > > If all processes are made runnable at once then both future > releases and acquisitions of the mutex may be uncontested, resulting > in not having to acquire the scheduling lock. I'm not sure we're talking about the same thing, but if so I must be missing something. If I'm waiting on a mutex, I still need to reacquire it on wakeup, don't I? In that case, only the first process to be scheduled will actually get the mutex, and the others will block again. > If the system is busy and there are not idle CPUs then there won't > be a thundering herd, because there is no herd to thunder. So we get a creeping herd? If we wake more processes than we can handle, we're just going to spend time putting the rest to sleep again. > The probability of threads blocking on the mutex before it is > released is a function of mutex hold time to the time it takes a > processor to calling switch with the thread which wants to run being > the highest priority. In general mutex hold time is small compared > to the time a process runs. Fine, but there are exceptions. Obviously if we only ever have one thread waiting on the mutex, we don't have any basis for discussion. <snip> > In general there ought not to be multiple processes piling > up on a mutex. If there are and for some reason they can't be > fixed then these particular mutexs are going to dictate how this > area is handled. Once we have these cases in hand we can make > some decisions as to how to proceed. In my experience, I've seen mutexes used for long-term waits, and I don't see any a priori reason not to do so. Of course, if we make design decisions based on the assumption that all waits will be short, then we will have a reason, but it won't be a good one. Before you say that long-term waits are evil, note that we're probably talking about different kinds of waits. Obviously anything that threatens to keep the system idle while it waits is bad, but a replacement for tsleep(), say, can justifiably wait for a long time. 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?20000704092245.B65029>