On Thu, Mar 5, 2009 at 11:48 AM, Michael Blizek <michi1@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx> wrote:
Hi!
The kernel can be preempted when you are holding a mutex or semaphore. This
On 23:47 Wed 04 Mar , sahlot arvind wrote:
> Hi All,
>
> Just had couple of questions:
>
> 1. kernel is preemptible if we are running in kernel mode and not holding
> any lock. What if we preempt the kernel even when we are holding lock?
> Assuming process A and B are trying to execute the same kernel path. So what
> if something like this happens:
> A gets into kernel mode and acquires a lock and then B comes, we preempt A
> and schedule B. B gets into kernel mode, tries to acquire the lock but its
> not available B goes to sleep, A gets the CPU again goes ahead does its job
> and releases the lock. B wakes up gets the lock and proceeds normal.
> Would there be any problem? I think no. Then why cannot we preempt kernel
> when we are holding a lock in kernel mode?
is not the case for spinlocks. The reason is that they are used by both
interrupt handlers and "normal" kernel code. Interrupt handlers cannot go to
sleep and let some other code run to release the lock. So if there is any
code which goes to sleep while holding a spinlock the kernel will hang when
any code tries to get the lock in the meantime.
Maybe... However it would need at least one stack per cpu and making the
> 2. If kernel is not preemptible then do we really need a separate kernel
> mode stack for each and every process? I mean cannot we use a common kernel
> mode stack for all and every process? I think we can because since only one
> process could be in the kernel mode at a time, any process getting into
> kernel mode can easily assume that the kernel mode stack is always free
> whenever it gets into kernel mode.
kernel non preemptive is bad for system responsiveness.
I think sleeping in the kernel will make using a common kernel stack extremely difficult (if not theoretically impossible).
Suppose, while running some code in the kernel, process A goes to sleep process B is scheduled. B will then use the stack for its own calls. If B too goes to sleep then there is no way that A can be run without B unwinding the stack first. Even if we decide to save the stack pointer separately for each process then, A will at some point, overwrite B's frames since they share the stack.
IMHO, the confusion lies in saying that 'only one process could be in the kernel mode at a time'. Although, on a uniprocessor machine only one process can be in the kernel mode at any given instant of time, more than one processes can be executing in kernel mode quasi-parallelly.
Kindly CMIIW...
Best regards,
Pranav
http://pranavsbrain.peshwe.com
