When is to preempt safe?

[Michael Blizek]

Hi!

On 19:27 Fri 07 Oct     , Parmenides wrote:
> Hi,
> 
>    Preemption has two cases: user preemption and kernel preemption. I
> have tow questions about them.
> 
> 1. According to Love, "If the kernel is returning to user-space, it
> knows it is in a safe quiescent state. In other words, if it is safe
> to continue executing the current task, it is also safe to pick a new
> task to execute." What's the meaning of user preemption's safety? How
> can we deduce safety of schedule from the current task going on?

Basically a task running in userspace in does not hold any kernel locks (see
below).

> 2. Another statement from Love is that "the kernel can preempt a task
> running in the kernel so long as it does not hold a lock". Why is it
> not safe while kernel code holding lock?

There are 2 different kind of locks: Those which can be preempted (mutex and
semaphores) and those which cannot (spinlocks). Spinlocks do busy waiting
until the lock is released. On single cpu systems, the are optimised into
enable/disable preemption. Spinlocks have to be used if the data it protects
is partly accessed in code paths which have preemption disables for other
reasons (e.g. being interrupt handler). This is because otherwise you have a
problem if you cannot preempt, but need to aquire a lock which is held by a
"thread" which has been preempted.

Also spinlocks *can* improve performance, because taking the lock tends be
faster if "threads" do not go to sleep while holding the lock. However, it
can also to the reverse: reducing responsiveness by running too long without
preemption.

	-Michi
-- 
programing a layer 3+4 network protocol for mesh networks
see http://michaelblizek.twilightparadox.com