Date: Tue, 27 Jun 2000 23:26:43 -0400 (EDT) From: Daniel Eischen <eischen@vigrid.com> To: Greg Lehey <grog@lemis.com> Cc: Jason Evans <jasone@canonware.com>, smp@FreeBSD.ORG Subject: Re: SMP meeting summary Message-ID: <Pine.SUN.3.91.1000627230450.18557A-100000@pcnet1.pcnet.com> In-Reply-To: <20000628130031.B1760@sydney.worldwide.lemis.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 28 Jun 2000, Greg Lehey wrote: > On Sunday, 25 June 2000 at 9:58:27 -0400, Daniel Eischen wrote: > > A Solaris (non-spinning) mutex will only spin while the owning thread is > > running. Since BSDi mutexes have owners (correct me if I'm wrong), this > > seems to be better than arbitrarily spinning. > > Mutexes only have owners when they're being held. But we won't spin > for any length of time on a mutex; that's why we have a thread context > for the interrupts. Right, I didn't think mutexes would have owners if they were not locked ;-) > > >> - BSD/OS also does not implement read/write locks, a thing that Linux > >> has recently introduced. We didn't discuss this further, but the > >> concepts are well understood, and it should be relatively simple to > >> implement them if we find a need. > > > > Mutexes are only used in Solaris when they will be held for very small > > amounts of time. Read/write locks and semaphores are used for all > > other instances. While we are modifying the kernel to add mutexes, > > it would probably be worthwhile to comment those sections of code > > that could hold mutexes for something other than a very short period > > of time. Or even use a different naming convention for those mutexes. > > Agreed, I don't like the terminology we seem to have settled on. From > my way of thinking, a mutex is a spin lock, and a semaphore is a > blocking lock. What we're talking about here are really semaphores, > though it makes sense to spin a bit first before blocking in the case > that the lock may be released quickly: it takes a fair amount of > overhead to schedule, and if there's a good chance the lock will be > available by the time we've scheduled, there's no point in blocking > immediately. It doesn't make sense to spin if the lock holder is not runnable, especially on a single CPU system. In order to make the owning thread runnable, you've got to take the scheduling queue lock and there has to be a context switch anyways. You might as well get ready to place the blocking thread on the sleep queue. If after acquiring (or while spinning on) the sleep queue lock, the owning thread becomes runnable, you can back out of the sleep queue insertion. > One of the things I want to do further down the line is > to instrument some statistics on the semaphores^H^H^Hnmutexes so we > can decide what kind we need where (and when). Great! Sounds like Solaris lockstat(1). > Greg > -- > Finger grog@lemis.com for PGP public key > See complete headers for address and phone numbers -- 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.1000627230450.18557A-100000>