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: | Daniel Eischen (eisc...@vigrid.com) | |
| Date: | Jun 27, 2000 8:26:21 pm | |
| List: | org.freebsd.freebsd-smp | |
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 gr...@lemis.com for PGP public key See complete headers for address and phone numbers
-- Dan Eischen
To Unsubscribe: send mail to majo...@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message