Actually the kernel lock is different to other spinlocks.
When a task holding the kernel lock blocks, i.e. calls schedule(), the
lock is dropped. When the task is run again, the lock is reacquired.
Ordinary spinlocks are different. You must never call schedule() while
holding an ordinary spinlock. This means no wait_on_blah() or down()
calls in the critical region, and no non-atomic memory allocation.
These rules don't apply to semaphores used as mutexes.
(But don't take my word for it. I can be wrong ;), read the source.
See release_kernel_lock(), reacquire_kernel_lock() and related() in
sched.c).
-- Jamie
-
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/
-
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/