On 2010-11-12 23:37, David Laight wrote:
On Thu, Nov 11, 2010 at 06:35:55PM +0100, Johnny Billquist wrote:this solution would break if people actually wrote code like lock(a) lock(b) release(a) release(b)That sequence is important, lock 'a' might control the global table, and lock 'b' a specific entry. Otherwise you have to exchange lock 'b' for a reference count in order to release 'a'. (this could apply to the pid lookup table)
So, if I understand you right, you use a spinlock mutex to lock the process table, to find a specific process. Then you use a spinlock mutex to lock a specific process, after which you can release the mutex for the process table?
Can you release b without taking a again? Else I see a nice potential for deadlocks here.
Even so, I wonder if spinlock mutexes are the thing here?Actually, this is horrible. Not only would it break in the face of the idea that each mutex held the previous IPL and restored it at the release, this code would probably break if the ipl was ever dropped below that of a as well.
This will only ever potentially have a gain in a MP system, where another processor could grab a. On the processor this is running, you need to essentially keep anyone else from doing the same thing in parallel, since that would cause a starvation.
spin locks needs to be kept tidy, since hanging on one can be rather fateful. You'd never want to do that, more that for the explicit possibility of multiprocessor situations.
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt%softjar.se@localhost || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol