Date: Fri, 24 Dec 2004 21:54:38 +0000 (GMT) From: Robert Watson <rwatson@freebsd.org> To: Jan Engelhardt <jengelh@linux01.gwdg.de> Cc: freebsd-hackers@freebsd.org Subject: Re: Kernel crash w/o reason Message-ID: <Pine.NEB.3.96L.1041224214958.27724B-100000@fledge.watson.org> In-Reply-To: <Pine.LNX.4.61.0412241311530.19395@yvahk01.tjqt.qr>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 24 Dec 2004, Jan Engelhardt wrote: > >> What should I use instead? A semaphore? > > >You shouldn't have unrelated kernel threads waiting for a user > >process at all, so this sounds like a design problem, regardless > >of which mutual exclusion primitive you use. (Bear in mind that I > >haven't actually looked into what you're trying to do.) In any > >case, you can always use mutexes to implement whatever other > >synchronization mechanism you need. > > I wanted that the device can only be opened once, and holding a mutex > while it is open seemed like a simple idea. (Since mtx_trylock() will > then fail -- easy to implement.) Typically a mutex (mutex(9)) is used only for small periods of mutual exclusion in accessing a data structure, and are not "sleepable locks" in which unbounded waiting may occur by a user process in kernel. For sleepable locks, you might want to investigate an sx lock (sx(9)), or possible construct a counted locking primitive using condition variables and mutexes (condvar(9)). I've not used our kernel counting semaphore implementation (sema(9)) but would assume it falls nicely into the second category and might be what you are looking for. FreeBSD kernel locking primitives are typically designed not to be held over potentially unbounded periods, such as "return to userspace", and only some are intended for use in semi-bounded periods (i.e., "wait on disk seek"). Most device drivers rely on a mutex and an internal access counter or exclusive bit, FYI. Robert N M Watson FreeBSD Core Team, TrustedBSD Projects robert@fledge.watson.org Principal Research Scientist, McAfee Research
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.NEB.3.96L.1041224214958.27724B-100000>