Date: Mon, 3 Jul 2000 08:49:43 -0700 (PDT) From: Frank Mayhar <frank@exit.com> To: Daniel Eischen <eischen@vigrid.com> Cc: Greg Lehey <grog@lemis.com>, Jason Evans <jasone@canonware.com>, Luoqi Chen <luoqi@watermarkgroup.com>, smp@FreeBSD.ORGG Subject: Re: SMP meeting summary Message-ID: <200007031601.JAA10893@realtime.exit.com> In-Reply-To: <Pine.SUN.3.91.1000703060948.5216A-100000@pcnet1.pcnet.com> from Daniel Eischen at "Jul 3, 2000 06:23:28 am"
next in thread | previous in thread | raw e-mail | index | archive | help
Daniel Eischen wrote: > Well if you are considering spinning for a bit of time on a held > mutex (which you seem to advocate?), then why not wake everyone? > If mutexes are held for very short periods of time and you don't > often have a thundering herd problem, then waking everyone is > an optimization since you only have to take the scheduling lock > once. If mutexes can be held for long periods of time, then you > probably wouldn't want to wake everyone. 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. :-) -- Frank Mayhar frank@exit.com http://www.exit.com/ Exit Consulting http://store.exit.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200007031601.JAA10893>