Date: Tue, 4 Jul 2000 12:09:30 +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: <20000704120930.G94351@wantadilla.lemis.com> In-Reply-To: <200007040218.UAA01169@berserker.bsdi.com> References: <200007040218.UAA01169@berserker.bsdi.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Monday, 3 July 2000 at 20:18:00 -0600, Chuck Paterson wrote: > >> 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. > > Yes, you need to acquire the mutex on wakeup, but likely > one process will run acquiring and releasing the mutex in an > uncontested fashion before other processes run and do the same > thing. Hmmm. Yes, I suppose that would happen in a single processor environment. >>> 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. > > A replacement for tsleep is not a mutex, but in Solaris > parlance a conditional variable. I think we have a certain problem with terminology, and it seems to be clouding the discussion. The big difference between the BSD/OS sleep mutex and the semaphores we used at Tandem (amongst other things for long-term waits) wasn't the counter (which was always set to 1) but the name. > The uses are different, one is for locking a resource, the other is > waiting on a synch event. A conditional variable, like the sleep > queues has a mutex associated with it. This mutex is not held except > while processing the event, both by the process waiting and the > process doing the activation. This is a different paradigm from the one we used. > I don't think it is a good idea to assume that the heuristics for > waking up tsleep / conditional variables is going to be anything > like those seen with mutexs. Maybe. I need to let this go through my head. Just because we found it to be the right idea at Tandem doesn't mean it's the right idea here. I've never been able to understand the advantages of conditional variables, which may be my viewpoint, or it may be some basic lack of understanding. > Since things have been cuts and pasted I'll say again I don't > have a good idea what the right answer is on any of this. I do > believe we need to get what we have running, instrument it, and > reach some decisions. Agreed entirely. At the moment the discussion is academic. When we've done the implementation, we'll have a much better idea about what we really want^H^H^H^Hneed. 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?20000704120930.G94351>