Date: Mon, 3 Jul 2000 22:41:27 -0400 (EDT) From: Daniel Eischen <eischen@vigrid.com> To: Greg Lehey <grog@lemis.com> Cc: Chuck Paterson <cp@bsdi.com>, Jason Evans <jasone@canonware.com>, Luoqi Chen <luoqi@watermarkgroup.com>, smp@freebsd.org Subject: Re: SMP meeting summary Message-ID: <Pine.SUN.3.91.1000703223707.29911C-100000@pcnet1.pcnet.com> In-Reply-To: <20000704092245.B65029@wantadilla.lemis.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 4 Jul 2000, Greg Lehey wrote: > 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. Which is why we want condition variables to replace tsleep(). If you want to wait long periods of time, then use condition variables or reader/writer locks. Mutex and condition variables can be used in a very similar way to splXXX() and tsleep(). -- 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.1000703223707.29911C-100000>