From owner-freebsd-smp Mon Jul 3 16:55:59 2000 Delivered-To: freebsd-smp@freebsd.org Received: from wantadilla.lemis.com (wantadilla.lemis.com [192.109.197.80]) by hub.freebsd.org (Postfix) with ESMTP id 8E7BA37BA9D for ; Mon, 3 Jul 2000 16:55:47 -0700 (PDT) (envelope-from grog@wantadilla.lemis.com) Received: (from grog@localhost) by wantadilla.lemis.com (8.9.3/8.9.3) id JAA93985; Tue, 4 Jul 2000 09:22:45 +0930 (CST) (envelope-from grog) Date: Tue, 4 Jul 2000 09:22:45 +0930 From: Greg Lehey To: Chuck Paterson Cc: Daniel Eischen , Jason Evans , Luoqi Chen , smp@freebsd.org Subject: Re: SMP meeting summary Message-ID: <20000704092245.B65029@wantadilla.lemis.com> References: <200007031528.JAA26798@berserker.bsdi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre2i In-Reply-To: <200007031528.JAA26798@berserker.bsdi.com> Organization: LEMIS, PO Box 460, Echunga SA 5153, Australia Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-418-838-708 WWW-Home-Page: http://www.lemis.com/~grog X-PGP-Fingerprint: 6B 7B C3 8C 61 CD 54 AF 13 24 52 F8 6D A4 95 EF Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org 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. > 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