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 _______________________________________________ Kernelnewbies mailing list Kernelnewbies@xxxxxxxxxxxxxxxxx http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
