Date: Mon, 03 Jul 2000 17:42:00 -0700 From: Joe Eykholt <jre@iprg.nokia.com> To: Greg Lehey <grog@lemis.com> Cc: "Jeroen C. van Gelderen" <jeroen@vangelderen.org>, 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: <396132D8.460539CA@iprg.nokia.com> References: <20000703114535.T39024@wantadilla.lemis.com> <Pine.SUN.3.91.1000703060948.5216A-100000@pcnet1.pcnet.com> <20000703200039.H62680@wantadilla.lemis.com> <3960A971.982DDF07@vangelderen.org> <20000704083822.A65029@wantadilla.lemis.com> <39612626.3E
next in thread | previous in thread | raw e-mail | index | archive | help
Greg Lehey wrote: > > On Monday, 3 July 2000 at 16:59:09 -0700, Joe Eykholt wrote: > > Joe Eykholt wrote: > >> > >> Greg Lehey wrote: > >> > >>> There's nothing to say that wake_one is more complex. wake_one takes > >>> the first process on the mutex's sleep list and wakes it. wake_all > >>> (or whatever) would make a loop out of that wake function and wake all > >>> the processes on the list. All would then be scheduled, try to take > >>> the mutex, and all except one would fail and be put back on the sleep > >>> list. Does this make sense? > >> > >> With adaptive mutexes, the threads which are woken will either run one > >> serially on one CPU, or some run at the same time on multiple CPUs. > >> In that case, one gets the lock right away, and the rest SPIN on it > >> (as long as the new owner doesn't get suspended on something else). > >> They don't necessarily go back to sleep on that same lock. > > > > Another thing that would happen if you don't wake all the waiters, > > and you have a lot of CPUs, is that a thread that comes along and wants > > the lock while the new owner is running (or before it's started running) > > either SPINs or acquires the lock in front of all of the threads > > that are still asleep. In other words it cuts in line. > > I need to look at the implementation more carefully. My understanding > is that the mutexes allow exactly one process to run, independent of > the number of processors (or any other resource on which they're > waiting). If we can allow multiple (but a finite number of) processes > to run concurrently, then we should be using counting semaphores > (which are, in fact, very similar to sleeping mutexes). Mutexes only allow one thread to get the mutex, but multiple threads can be spinning for the mutex. Wake_one (or wake_all) doesn't give the mutex to anyone, the threads must to get scheduled by a CPU and then ACQUIRE the mutex ... which is hopefully still free at that time. If we wake_all, then all of the threads will try to get the mutex once they have a CPU. As long as the thread owning the mutex is on a CPU, the other contenders spin. Semaphores are tough to use adaptively, since there's no identifiable 'owner'. Joe 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?396132D8.460539CA>