Date: Mon, 25 Sep 2000 20:06:09 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: arch@freebsd.org Cc: tlambert@primenet.com Subject: Re: Mutexes and semaphores (was: cvs commit: src/sys/conf files Message-ID: <200009252006.NAA00200@usr02.primenet.com> In-Reply-To: <200009251940.MAA02445@vashon.polstra.com> from "John Polstra" at Sep 25, 2000 12:40:21 PM
next in thread | previous in thread | raw e-mail | index | archive | help
> > Recursion should be such an exceptional condition that it should > > be implemented with a seperate struct and a counting semaphore. > > > > Counting semaphores have owners,; mutexes do not. Therefore they > > are a more appropriate primitive. > > You are wrong. Counting semaphores do not keep track of owners. OK. Let's be pedantic. Neither do mutexes. Counting semaphores are a more appropriate primitive, as the "resource" which is counted is the ownership capability. As others have pointed out (Archie, etc.), a semaphore with a count of 1 is appropriate. When the count goes 1->0, then we can consider that ownership has been relinquished. > The count has nothing to do with that at all. The count holds the > number of available "units" of whatever resource the semaphore is > controlling access to. It is the number of "P" operations that can > be done without blocking. That is completely different from the > recursion count of a recursive mutex, which keeps track of the number > of times the current owner has acquired the mutex, and therefore the > number of releases the owner must do before somebody else can acquire > the mutex. I never stated that the recursion count would be implemented in the semaphore count of a counting semaphore. Please read the first quoted sentence again. Ownership and recursion are kept in the seperate struct. > Don't take my word for it. Do the Google search as I suggested, or go > to the sample URL I gave you, or read any decent book or tutorial on > the subject. Or, since you've cited Windows as having done it right, > read their documentation on semaphores. Windows did semaphores right. Windows did mutexes wrong. Like idiots, they permitted recursion. Since any user space thread or timer can run on any kernel thread, and the mutex holder is based on the kernel thread ID, not the higher level context ID currently mapped to the thread, you can have situations where you have a resource contended by two user space entities mapped to a single kernel thread backing object (consider that FreeBSD will act similarly with N:M threads). To get around this, you have to implement non-recusing mutexes using a semaphore of count 1. Matt Day, Mark Muhlestein, and I ran into this when we implemented the syncd as a timer outcall when we ported the Heidemann stacking VFS framework to Windows 95, and implemented soft updates in FFS on Windows 95, back in 1995-1996. With recrusion permitted mutexes, people will find themselves reinventing this for FreeBSD in order ot get non-recursing mutexes for similar situations. 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?200009252006.NAA00200>