Date: Tue, 12 Sep 2000 14:38:55 +0930 From: Greg Lehey <grog@lemis.com> To: Chuck Paterson <cp@bsdi.com> Cc: Jason Evans <jasone@canonware.com>, arch@freebsd.org Subject: Re: Long-term mutex ownership (was Re: Interruptable mutex aquires.) Message-ID: <20000912143855.O88615@wantadilla.lemis.com> In-Reply-To: <200009120404.WAA25503@berserker.bsdi.com>; from cp@bsdi.com on Mon, Sep 11, 2000 at 10:04:28PM -0600 References: <200009120404.WAA25503@berserker.bsdi.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Monday, 11 September 2000 at 22:04:28 -0600, Chuck Paterson wrote: >> I don't recall the original argument against holding mutexes for long >> periods. From an abstract point of view, there's nothing wrong with such >> practice, and in fact it makes sense for many problems. Is there an issue >> with our implementation? If so, can someone please explain it? > > If you hold a mutex across a sleep call then release of the > mutex becomes dependent upon another process. This makes it > impossible (at least from a practical point of view) to prove that > there are not deadlocks. That depends on what locks you're holding, and who else would be interested in them. > From my experience I was use to mutexs being held across sleep > (async event waits) calls. Eric Varsanyi whose background was Cray, > rather than Sun, thought we should do without them until they were > needed. That's definitely a good idea :-) > It turned out that we didn't really need them at all Well, that depends on how satisfied you are with tsleep. > so we decided to go without and not have to fight the dead lock > issues. It wasn't as if we could do with out them, it was not an > issue at all. The general consensus (which I currently don't yet share) is that we should use condition variables for things like async event waits. I'm still looking for a consistent definition of condition variables, and how they differ from "mutexes". > Mutex are for protecting data there are other mechanism for doing > the other types of synchronization. In the current system, this is correct. That doesn't mean it's necessarily the optimum. The thing I'm looking at most here is tsleep (which we have renamed msleep because of the additional mutex parameter). The real problem is wakeup: we need to search a list of processes, which is slow, and wakeup itself needs to go to the bitter end. Yes, we can use wakeup_one (which stops at the first proc with the right p_wchan), but we still need to search an average of half the chain. We have 128 hash buckets, but that's not many for a system which could have thousands of processes active. The obvious alternative is an object on which you can queue waiting processes, whether we want to call it a mutex, semaphore, condition variable or turnstile. I really need to think out some simple examples. Everything we've been doing lately looks so complicated, and though we can understand the complexity relatively well, I think it's making it difficult to gain an overview. I think our arguments are showing more our individual perspective than any real difference in viewpoint. Greg -- Finger grog@lemis.com for PGP public key See complete headers for address and phone numbers To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20000912143855.O88615>