Daniel Eischen wrote:

I'm going to use Daniel's email as a springboard for a strongly-held opinion. I really, really wish that you guys would get away from using the term "mutex" for both short- and long-term locks. All a mutex is is a lock; it says nothing about what kind of lock, whether it sleeps or spins or even whether it's a reader/writer lock. It's the most generic term available.

How about "spinlock" for short-term spin locks, "sleeplock" for long-term blocking locks and "rwlock" for reader/writer locks (modified by whether it's a spinlock or a sleeplock)? That would add clarity, I think. Maybe it's my SVR4/Unixware experience, but I always have to figure out whether someone is talking about a spinlock or a sleeplock from context.

To address Dan's real question, it depends on whether, after spinning for a short time, the spinlock decides to become a sleeplock (in other words, it's a hybrid). If it sleeps, depending on the implementation there could be a thundering herd problem, since you have no idea how long it's going to sleep or how many threads/processes will be on the chain. Basically, all a hybrid lock is is an optimization of a sleeplock that speeds up the (possibly common) case of a sleeplock being held for a short time relative to the waiting process.

(Any errors here are my own and will undoubtedly be promptly corrected by the audience. :-)

To Unsubscribe: send mail to majo...@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message