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: b...@softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol