Date: Tue, 27 Jun 2000 20:25:57 -0700 From: Jason Evans <jasone@canonware.com> To: Greg Lehey <grog@lemis.com> Cc: Daniel Eischen <eischen@vigrid.com>, smp@FreeBSD.ORG Subject: Re: SMP meeting summary Message-ID: <20000627202557.S15267@blitz.canonware.com> In-Reply-To: <20000628130031.B1760@sydney.worldwide.lemis.com>; from grog@lemis.com on Wed, Jun 28, 2000 at 01:00:31PM %2B1000 References: <20000624235605.D8965@blitz.canonware.com> <Pine.SUN.3.91.1000625091445.2784A-100000@pcnet1.pcnet.com> <20000628130031.B1760@sydney.worldwide.lemis.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Jun 28, 2000 at 01:00:31PM +1000, Greg Lehey wrote: > On Sunday, 25 June 2000 at 9:58:27 -0400, Daniel Eischen wrote: > > On 24 Jun 2000, Jason Evans wrote: > >> - 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. 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). Mutexes come in different flavors. From an API perspective, whether the mutex spins, blocks, or is adaptive isn't visible. A semaphore is significantly different. It can be used in place of a mutex, but it has additional functionality. A POSIX semaphore has a count associated with it. Other definitions of semaphores generally have a count associated with the semaphore as well, though there may be more functionality than POSIX semaphores provide. Posting (incrementing) the semaphore always succeeds, but waiting on (decrementing) the semaphore will spin/block until the decrement operation can be completed without the semaphore value becoming negative. So, both mutexes and semaphores can be implemented as spinning/blocking/adaptive. Jason 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?20000627202557.S15267>