Date: Wed, 28 Jun 2000 14:59:55 +1000 From: Greg Lehey <grog@lemis.com> To: Jason Evans <jasone@canonware.com> Cc: Daniel Eischen <eischen@vigrid.com>, smp@FreeBSD.ORG Subject: Re: SMP meeting summary Message-ID: <20000628145955.A2209@sydney.worldwide.lemis.com> In-Reply-To: <20000627202557.S15267@blitz.canonware.com> References: <20000624235605.D8965@blitz.canonware.com> <Pine.SUN.3.91.1000625091445.2784A-100000@pcnet1.pcnet.com> <20000628130031.B1760@sydney.worldwide.lemis.com> <20000627202557.S15267@blitz.canonware.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tuesday, 27 June 2000 at 20:25:57 -0700, Jason Evans wrote: > 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. Hmm. I haven't seen the POSIX definition, but Dijkstra's semaphores had a count and two main operations, P and V. P decrements, and if the semaphore counter goes negative, the process is placed on the semaphore sleep queue. If V increments to 0, the first process on the sleep queue is scheduled. The mutexes we're looking at here are a degenerate case of semaphores: instead of a count, we have a flag (in fact, a predicate) that says whether the semaphore is held or not. That's effectively a semaphore with an initial counter value of 0. > So, both mutexes and semaphores can be implemented as > spinning/blocking/adaptive. I was pretty sure that a semaphore was always blocking. 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?20000628145955.A2209>