Date: Tue, 12 Sep 2000 18:09:03 +1200 From: Joerg Micheel <joerg@cs.waikato.ac.nz> To: Greg Lehey <grog@lemis.com> Cc: Chuck Paterson <cp@bsdi.com>, Jason Evans <jasone@canonware.com>, arch@freebsd.org, joerg@cs.waikato.ac.nz Subject: Re: Long-term mutex ownership (was Re: Interruptable mutex aquires.) Message-ID: <20000912180903.B70000@cs.waikato.ac.nz> In-Reply-To: <20000912143855.O88615@wantadilla.lemis.com>; from grog@lemis.com on Tue, Sep 12, 2000 at 02:38:55PM %2B0930 References: <200009120404.WAA25503@berserker.bsdi.com> <20000912143855.O88615@wantadilla.lemis.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Sep 12, 2000 at 02:38:55PM +0930, Greg Lehey wrote: > 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". There is no memory associated with condition variables. Someone can grab a mutex. The condition variable is a rendevous thing - you signal on it. If someone is waiting - fine, they get a ring. > 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. You are discussing implementation here. The mutex is a replacement for splx() locking. The condition variable is a replacement for sleep()/wakeup() on multiprocessors. Likewise, for a rendevous on a cv, you need to hold a mutex, much like having to raise the splx() level before going on sleep(). It is not necessarily the best model to think of it, but something that everyone beeing around in UNIX for the past 20 years can understand with not too much effort. The rw_lock is a new smart way to improve parallism, it is much the same as a mutex, only you need to tell what you are going to do and that determines whether you are allowed to enter. Apart from that it is identical to the mutex. > 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. That's the programmers (users) perspective. I think you really just have two different "things": mutex and cond variable (the rw_lock being sugar coating). As you said, the FreeBSD term for condition variable is the msleep() mechanism. You need mutexes in addition. Do you think this is too much ? Too little structure ? Joerg -- Joerg B. Micheel Email: <joerg@cs.waikato.ac.nz> Waikato Applied Network Dynamics Phone: +64 7 8384794 The University of Waikato, CompScience Fax: +64 7 8585095 Private Bag 3105 Pager: +64 868 38222 Hamilton, New Zealand Plan: TINE and the DAG's 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?20000912180903.B70000>