Date: Mon, 25 Sep 2000 19:09:28 -0700 (PDT) From: John Polstra <jdp@polstra.com> To: arch@freebsd.org Cc: tlambert@primenet.com Subject: Re: Mutexes and semaphores (was: cvs commit: src/sys/conf files Message-ID: <200009260209.TAA03815@vashon.polstra.com> In-Reply-To: <200009252235.PAA07367@usr07.primenet.com> References: <200009252235.PAA07367@usr07.primenet.com>
next in thread | previous in thread | raw e-mail | index | archive | help
In article <200009252235.PAA07367@usr07.primenet.com>, Terry Lambert <tlambert@primenet.com> wrote: > Fine. Then we're agreed: non-recursive mutexes are the base unit, > and recursion will be implemented on a case by case basis using > an additional structure, which contains a non-recursive mutex, a > recursion counter, and an owner field. That's simply a less efficient implementation of a recursive mutex. Why not use the real thing? > Glad that's settled, until the first time a thread migrates between > processors, and we decide we need a semaphore instead of a mutex as > a primitive in order to handle sleeps and wakeups that occur with > a mutex with a recursion count greater than 0, for some ungodly > reason. Now we're back practically to my original question. Explain how a semaphore is going to solve anything here. I don't think it will help one bit. In virtually all cases which require sleeping and being woken up (whether via a condition variable or a semaphore), the basic scenario is the same. Thread A is examining and/or modifying a shared data structure. Now he wants to wait until thread B modifies the data structure and puts it into some desired state. While A was examining/modifying the data structure, he necessarily held a mutex on it in order to get a consistent view. Before he waits, he must release that mutex -- otherwise B won't be able to make the desired modifications. This is true whether the waiting is done with a condition variable or with a semaphore. It really doesn't make much difference which one you use. The only difference is that when using a condition variable the "release mutex and wait" sequence must be atomic, because a condition variable doesn't "remember" a wakeup that happened when nobody was waiting yet. A semaphore does remember it, so there is no need for atomicity with respect to releasing the mutex. That's a pretty minor difference, and it doesn't have anything to do with whether the mutexes are recursive or not. If the mutex is recursively held, there is a problem in that some other code grabbed the mutex and expected it to protect the data structure from being changed underfoot. Using a semaphore to do the waiting doesn't solve that problem, or even address it. John -- John Polstra jdp@polstra.com John D. Polstra & Co., Inc. Seattle, Washington USA "Disappointment is a good sign of basic intelligence." -- Chögyam Trungpa 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?200009260209.TAA03815>