Andi Kleen <ak@suse.de> wrote:
> This is far from a single CPU instruction between the test_bit and the
> set_bit. Even with a single CPU instruction you would need a cmpxchg with
> retry BTW, to handle the case of multiple CPUs entering the instruction at
> the same time. The easiest fix is to add a spinlock per mutex.
>
> if (test_bit(0,&mutex->wm_state) || mutex->wm_owner!=filp) {
> ret = 0; /* false */
> } else {
> ret = 1;
> mutex->wm_owner = NULL;
> set_bit(0,&mutex->wm_state);
> SignalObject(obj,1);
> }
I see what you're getting at... (I was thinking of the mutex grab stage, not
the release stage).
Anyway, I though I could get away with it, but on reflection, perhaps
not... If two threads of the same process try and issue ReleaseMutex()
simultaneously on one mutex, then theoretically, one should succeed and the
other fail, but given the above code, you are right... there would be a race.
Between threads of different "processes" I don't think it'll actually be a
problem, since mutex theft isn't permitted. I also don't think there'll be a
conflict between grab and release, since the actual release is the last thing
done by the ReleaseMutex function, and the actual grab is the first thing done
by the MutexPoll function.
But you are right... It should be guarded anyway. Perhaps what I should do is
to use the owner field as the mutex (NULL is available) and use cmpxchgl to do
the grab _and_ the release.
David Howells
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Thu Sep 07 2000 - 21:00:30 EST