From owner-freebsd-arch Sun Sep 24 20:15:53 2000 Delivered-To: freebsd-arch@freebsd.org Received: from smtp04.primenet.com (smtp04.primenet.com [206.165.6.134]) by hub.freebsd.org (Postfix) with ESMTP id 0A2E637B422; Sun, 24 Sep 2000 20:15:47 -0700 (PDT) Received: (from daemon@localhost) by smtp04.primenet.com (8.9.3/8.9.3) id UAA10301; Sun, 24 Sep 2000 20:13:10 -0700 (MST) Received: from usr05.primenet.com(206.165.6.205) via SMTP by smtp04.primenet.com, id smtpdAAAXaayeu; Sun Sep 24 20:13:08 2000 Received: (from tlambert@localhost) by usr05.primenet.com (8.8.5/8.8.5) id UAA04888; Sun, 24 Sep 2000 20:15:30 -0700 (MST) From: Terry Lambert Message-Id: <200009250315.UAA04888@usr05.primenet.com> Subject: Re: Mutexes and semaphores (was: cvs commit: src/sys/conf files src/sys/sys random.h src/sys/dev/randomdev hash.c hash.h harvest To: cp@bsdi.com (Chuck Paterson) Date: Mon, 25 Sep 2000 03:15:30 +0000 (GMT) Cc: grog@wantadilla.lemis.com (Greg Lehey), archie@whistle.com (Archie Cobbs), brian@awfulhak.org (Brian Somers), joerg@cs.waikato.ac.nz (Joerg Micheel), mjacob@feral.com (Matthew Jacob), frank@exit.com (Frank Mayhar), jhb@pike.osd.bsdi.com (John Baldwin), markm@FreeBSD.ORG (Mark Murray), FreeBSD-arch@FreeBSD.ORG In-Reply-To: <200009241948.NAA25438@berserker.bsdi.com> from "Chuck Paterson" at Sep 24, 2000 01:48:45 PM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > First a general comment. The main reason to not hold a mutex across > an async event is not because it won't work, but because it means > that we loose the ability to detect dead locks. If process A holds > mutex bar during a wait for async event, such as msleep(), then it > becomes a requirment that the process which is going to wake up > process A doesn't block on mutex foo, or have any dependencies even > many removed on something that requires mutex bar. Yes. The appropriate tool for doing this type of thing is a condition variable. The condition is tested under mutex protection. If false, the thread blocks on the variable and atomically releases the mutex. When the condition is satisfied, the variable is changed (again, under the protection of the mutex), and one or more threads waiting on the condition are signalled. The thread(s) signalled will attempt to reacquire the mutex, and, when successful, examine the variable, and take appropriate action, which might be to go back to sleep, if the condition is no longer satisfied, due to a lost race. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message