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: | Joe Eykholt (jr...@iprg.nokia.com) | |
| Date: | Jul 3, 2000 5:41:38 pm | |
| List: | org.freebsd.freebsd-smp | |
Greg Lehey wrote:
On Monday, 3 July 2000 at 16:59:09 -0700, Joe Eykholt wrote:
Joe Eykholt wrote:
Greg Lehey wrote:
There's nothing to say that wake_one is more complex. wake_one takes the first process on the mutex's sleep list and wakes it. wake_all (or whatever) would make a loop out of that wake function and wake all the processes on the list. All would then be scheduled, try to take the mutex, and all except one would fail and be put back on the sleep list. Does this make sense?
With adaptive mutexes, the threads which are woken will either run one serially on one CPU, or some run at the same time on multiple CPUs. In that case, one gets the lock right away, and the rest SPIN on it (as long as the new owner doesn't get suspended on something else). They don't necessarily go back to sleep on that same lock.
Another thing that would happen if you don't wake all the waiters, and you have a lot of CPUs, is that a thread that comes along and wants the lock while the new owner is running (or before it's started running) either SPINs or acquires the lock in front of all of the threads that are still asleep. In other words it cuts in line.
I need to look at the implementation more carefully. My understanding is that the mutexes allow exactly one process to run, independent of the number of processors (or any other resource on which they're waiting). If we can allow multiple (but a finite number of) processes to run concurrently, then we should be using counting semaphores (which are, in fact, very similar to sleeping mutexes).
Mutexes only allow one thread to get the mutex, but multiple threads can be spinning for the mutex. Wake_one (or wake_all) doesn't give the mutex to anyone, the threads must to get scheduled by a CPU and then ACQUIRE the mutex ... which is hopefully still free at that time. If we wake_all, then all of the threads will try to get the mutex once they have a CPU. As long as the thread owning the mutex is on a CPU, the other contenders spin.
Semaphores are tough to use adaptively, since there's no identifiable 'owner'.
Joe
To Unsubscribe: send mail to majo...@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message