Nope, not acceptable.
The mm semaphore is one of the most timing-critical in the whole kernel.
It usually has absolutely zero contention, but it needs to be FAST.
Basically, a read-lock() must look something very very similar to the
read-spinlock implementation, ie something like
lock ; incl (%ecx)
js fixup
for the successful fall-through case. Two instructions, no more. That's
what the spinlocks do, and that's also what the semaphores do (although in
the case of a semaphore, it's a "decl" in that case.
The "fixup" case is going to be more complex than for spinlocks: for
spinlocks it's just a simple loop, while for semaphores you get all the
complexity that you see in arch/i386/kernel/semaphore.c to handle the
thing cleanly..
The read-write semaphore should be doable with the same skeleton as the
normal semaphores, although it needs two counters (regular semaphores have
just "sleepers", rw-semaphores need to have "read_sleeper" and
"write_sleeper" counts etc).
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/