|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:||Terry Lambert (tlam...@primenet.com)|
|Date:||Jul 5, 2000 4:00:27 pm|
}I'm not sure we're talking about the same thing, but if so I must be }missing something. If I'm waiting on a mutex, I still need to }reacquire it on wakeup, don't I? In that case, only the first process }to be scheduled will actually get the mutex, and the others will block }again.
Yes, you need to acquire the mutex on wakeup, but likely one process will run acquiring and releasing the mutex in an uncontested fashion before other processes run and do the same thing.
You can assume in SVR4, in the wake_one case, that you will be the only process awake, and so your acquisition will not be contested, and will not result in a sleep.
Logically, you can consider that there is one waiter and N-1 sleepers for every N processses trying to acquire a mutex.
This is normally handled [in the literature] by using a hybrid lock in a hierarchy.
That is, you attempt a fast lock, and if that fails, then you attempt a slow ("sleeping") lock. You are guaranteed a wakeup on release of a fast lock, and on release of a sleeping lock, so it's sixes,
Of course, it's a lot easier to just critical section.
}In my experience, I've seen mutexes used for long-term waits, and I }don't see any a priori reason not to do so. Of course, if we make }design decisions based on the assumption that all waits will be short, }then we will have a reason, but it won't be a good one. } }Before you say that long-term waits are evil, note that we're probably }talking about different kinds of waits. Obviously anything that }threatens to keep the system idle while it waits is bad, but a }replacement for tsleep(), say, can justifiably wait for a long time.
A replacement for tsleep is not a mutex, but in Solaris parlance a conditional variable. The uses are different, one is for locking a resource, the other is waiting on a synch event. A conditional variable, like the sleep queues has a mutex associated with it. This mutex is not held except while processing the event, both by the process waiting and the process doing the activation. I don't think it is a good idea to assume that the heuristics for waking up tsleep / conditional variables is going to be anything like those seen with mutexs.
Effectively, condition variables are critical sectioned in their manipulation through the use of a mutex.
In practice, there are some ugly areas in the Solaris SMP reentrant VFS code that necessitate trating the cond variable as if it were a mutext on a larger structure. This reduces concurrency considerably.
The main point about wake_one that's problematic is the deadly embrace deadlock, not the priority inversion deadlock, which can always be "opted out of" by lending (or making the wake_one more choosy about who it wakes, above and beyond the head of the wait queue).
The thing that makes a thundering herd expensive is less the herd than it is the traversal of the list; think about it: if I have the cycles to burn in the scheduler to pick someone to run, then I wasn't doing important other work anyway, and I might as well burn them in the herd, as opposed to other places I could burn them.
A spinlock fixes this by implementing back-off + retry, at least for sets of two locks. Sets of more locks are really problematic.
A lot of work was done in SVR4 ES/MP to, effectively, resolve the problem using Djikstra's "Banker's Algorithm" (that is, all the resources for sets of greater than two members, and in some cases, one member -- usually parent directory in a descending path lookup -- are allocated "up front", which is to say "at the same stack depth/in the same function" to permit state to be backed out easily in the case of a deadlock detection).
This stuff is really unsatisfying from the point of view of someone trying to write a reentrant ("kernel thread safe" or "kernel preemption safe") VFS provider of some kind, since it's really hard to know when the semantics applied by an upper level function might result in a problem. Other subsystems have similar issues, but most of my experience was with VFS providers, so I can't give you the PCMCIA device attach issues in SVR4 (maybe we can track down Kurt Mahon, though).
Terry Lambert ter...@lambert.org
--- Any opinions in this posting are my own and not those of my present or previous employers.
To Unsubscribe: send mail to majo...@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message