Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 25 Sep 2000 03:15:30 +0000 (GMT)
From:      Terry Lambert <tlambert@primenet.com>
To:        cp@bsdi.com (Chuck Paterson)
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
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
Message-ID:  <200009250315.UAA04888@usr05.primenet.com>
In-Reply-To: <200009241948.NAA25438@berserker.bsdi.com> from "Chuck Paterson" at Sep 24, 2000 01:48:45 PM

next in thread | previous in thread | raw e-mail | index | archive | help
> 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




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200009250315.UAA04888>