Date: Fri, 16 Jan 2004 17:07:09 -0500 From: John Baldwin <jhb@FreeBSD.org> To: des@des.no (Dag-Erling =?iso-8859-1?q?Sm=F8rgrav?=), src-committers@FreeBSD.org Cc: cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/kern kern_descrip.c Message-ID: <200401161707.09423.jhb@FreeBSD.org> In-Reply-To: <xzpn08nsgik.fsf@dwp.des.no> References: <200401162154.i0GLsuKq056578@repoman.freebsd.org> <xzpn08nsgik.fsf@dwp.des.no>
next in thread | previous in thread | raw e-mail | index | archive | help
On Friday 16 January 2004 04:57 pm, Dag-Erling Smørgrav wrote: > Dag-Erling Smorgrav <des@FreeBSD.org> writes: > > WITNESS won't let us hold two filedesc locks at the same time, so > > juggle fdp and newfdp around a bit. > > The question though is, is there a real reason why we can't hold two > filedesc locks at the same time, or is WITNESS being unnecessarily > pedantic? In this case you are safe because one lock doesn't even need to be held at all. However, in the normal case this is a very valid check. It is only safe to acquire two locks of the same type if you have a well-defined order in the way that you lock multiple locks. For example, for proc locks, when we do acquire them multiple times we either 1) use mtx_trylock() (which can't block, so it's not a problem) or 2) we lock the child process first and the parent process second. If you just arbitrarily lock two of the same type of lock then you can get a deadlock if two different threads are trying to lock the two same locks in reverse order. This can happen if you forget to unlock a lock also for example. It is best to let WITNESS catch as many errors as possible rather than just shutting them up for one special case that you don't wish to work around. Esp. if that one case is locking something that doesn't even need to be locked. :-) -- John Baldwin <jhb@FreeBSD.org> <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200401161707.09423.jhb>