Date: Mon, 03 Jul 2000 20:18:00 -0600 From: Chuck Paterson <cp@bsdi.com> To: Greg Lehey <grog@lemis.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: <200007040218.UAA01169@berserker.bsdi.com>
next in thread | raw e-mail | index | archive | help
}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. } }> 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. } Perhaps, but odds are not see next graph. }> 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. A replacement for tsleep is not a mutex, but in Solaris parlance a conditional variable. 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. 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. 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. Chuck 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?200007040218.UAA01169>