From owner-freebsd-arch Mon Sep 25 19: 9:42 2000 Delivered-To: freebsd-arch@freebsd.org Received: from wall.polstra.com (rtrwan160.accessone.com [206.213.115.74]) by hub.freebsd.org (Postfix) with ESMTP id B6FB937B42C for ; Mon, 25 Sep 2000 19:09:34 -0700 (PDT) Received: from vashon.polstra.com (vashon.polstra.com [206.213.73.13]) by wall.polstra.com (8.9.3/8.9.3) with ESMTP id TAA19160; Mon, 25 Sep 2000 19:09:29 -0700 (PDT) (envelope-from jdp@polstra.com) From: John Polstra Received: (from jdp@localhost) by vashon.polstra.com (8.9.3/8.9.1) id TAA03815; Mon, 25 Sep 2000 19:09:28 -0700 (PDT) (envelope-from jdp@polstra.com) Date: Mon, 25 Sep 2000 19:09:28 -0700 (PDT) Message-Id: <200009260209.TAA03815@vashon.polstra.com> To: arch@freebsd.org Reply-To: arch@freebsd.org Cc: tlambert@primenet.com Subject: Re: Mutexes and semaphores (was: cvs commit: src/sys/conf files In-Reply-To: <200009252235.PAA07367@usr07.primenet.com> References: <200009252235.PAA07367@usr07.primenet.com> Organization: Polstra & Co., Seattle, WA Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In article <200009252235.PAA07367@usr07.primenet.com>, Terry Lambert 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