65 messages in org.freebsd.freebsd-smpRe: SMP meeting summary| From | Sent On | Attachments |
|---|---|---|
| Jason Evans | Jun 24, 2000 11:56 pm | |
| Daniel Eischen | Jun 25, 2000 6:58 am | |
| Terry Lambert | Jun 25, 2000 10:12 am | |
| Terry Lambert | Jun 25, 2000 10:36 am | |
| Julian Elischer | Jun 25, 2000 10:41 am | |
| Poul-Henning Kamp | Jun 25, 2000 11:07 am | |
| Nate Williams | Jun 25, 2000 9:41 pm | |
| Frank Mayhar | Jun 25, 2000 11:27 pm | |
| Frank Mayhar | Jun 25, 2000 11:31 pm | |
| Luoqi Chen | Jun 26, 2000 9:46 am | |
| Arun Sharma | Jun 26, 2000 9:47 am | |
| Jason Evans | Jun 26, 2000 11:06 am | |
| Matthew Dillon | Jun 26, 2000 12:26 pm | |
| Matthew Dillon | Jun 26, 2000 12:48 pm | |
| John Sconiers | Jun 26, 2000 12:56 pm | |
| Matthew Dillon | Jun 26, 2000 1:07 pm | |
| Luoqi Chen | Jun 26, 2000 1:13 pm | |
| Doug Rabson | Jun 26, 2000 1:26 pm | |
| Jason Evans | Jun 26, 2000 2:56 pm | |
| Jason Evans | Jun 26, 2000 3:14 pm | |
| Daniel Eischen | Jun 26, 2000 4:59 pm | |
| Luoqi Chen | Jun 26, 2000 7:14 pm | |
| Jason Evans | Jun 26, 2000 7:55 pm | |
| Joe Eykholt | Jun 26, 2000 8:09 pm | |
| Greg Lehey | Jun 27, 2000 8:00 pm | |
| Jason Evans | Jun 27, 2000 8:25 pm | |
| Daniel Eischen | Jun 27, 2000 8:26 pm | |
| Greg Lehey | Jun 27, 2000 9:59 pm | |
| Greg Lehey | Jun 27, 2000 10:11 pm | |
| Terry Lambert | Jun 28, 2000 4:15 pm | |
| Terry Lambert | Jun 28, 2000 4:18 pm | |
| Terry Lambert | Jun 28, 2000 4:37 pm | |
| Terry Lambert | Jun 28, 2000 4:51 pm | |
| Arun Sharma | Jun 28, 2000 9:43 pm | |
| Greg Lehey | Jul 2, 2000 7:15 pm | |
| Daniel Eischen | Jul 3, 2000 3:23 am | |
| Greg Lehey | Jul 3, 2000 3:30 am | |
| Jeroen C. van Gelderen | Jul 3, 2000 7:55 am | |
| Chuck Paterson | Jul 3, 2000 8:28 am | |
| Chuck Paterson | Jul 3, 2000 8:47 am | |
| Frank Mayhar | Jul 3, 2000 8:49 am | |
| Greg Lehey | Jul 3, 2000 4:08 pm | |
| David Scheidt | Jul 3, 2000 4:35 pm | |
| Joe Eykholt | Jul 3, 2000 4:47 pm | |
| Greg Lehey | Jul 3, 2000 4:52 pm | |
| Joe Eykholt | Jul 3, 2000 4:58 pm | |
| Greg Lehey | Jul 3, 2000 5:26 pm | |
| Joe Eykholt | Jul 3, 2000 5:41 pm | |
| Chuck Paterson | Jul 3, 2000 7:17 pm | |
| Daniel Eischen | Jul 3, 2000 7:25 pm | |
| Daniel Eischen | Jul 3, 2000 7:35 pm | |
| Greg Lehey | Jul 3, 2000 7:39 pm | |
| Daniel Eischen | Jul 3, 2000 7:41 pm | |
| Chuck Paterson | Jul 3, 2000 8:40 pm | |
| Alfred Perlstein | Jul 3, 2000 10:08 pm | |
| Greg Lehey | Jul 3, 2000 10:37 pm | |
| Peter Wemm | Jul 4, 2000 2:43 pm | |
| Greg Lehey | Jul 4, 2000 3:58 pm | |
| Peter Wemm | Jul 4, 2000 4:06 pm | |
| Terry Lambert | Jul 5, 2000 3:38 pm | |
| Terry Lambert | Jul 5, 2000 4:00 pm | |
| Terry Lambert | Jul 5, 2000 4:06 pm | |
| Terry Lambert | Jul 5, 2000 4:10 pm | |
| Alfred Perlstein | Jul 5, 2000 4:29 pm | |
| Terry Lambert | Jul 6, 2000 4:50 pm |
| Subject: | Re: SMP meeting summary | |
|---|---|---|
| From: | Greg Lehey (gr...@lemis.com) | |
| Date: | Jun 27, 2000 9:59:33 pm | |
| List: | org.freebsd.freebsd-smp | |
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 gr...@lemis.com for PGP public key See complete headers for address and phone numbers
To Unsubscribe: send mail to majo...@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message