Questions about preemption and concurrency

[michi1@michaelblizek.twilightparadox.com (Michael Blizek)]

Hi!

On 17:14 Fri 27 May     , Naman shekhar Mishra wrote:
> In Operating System Concepts 6th ed, chapter 20:
> "Kernel code can thus assume that it will never be preempted by another process and that no special care must be
> taken to protect critical sections.

This is very simplified and hardly true:
1) In some cases kernel code can be preempted. Otherwise latencies would be
very long. Even if you disable kernel preemption, calls to schedule() may
still cause "preemption". This can actually be complex on its own: You have to
make sure that you are in a consistent state when you resume.
2) On a system with more than one CPU, you need to make sure that one one CPU
is running in kernel mode. Linux had this thing called "big kernel lock" to do
this. However, it did not scale very well.

> The only requirement is that critical sections do not contain references to user memory
> or waits for I/O completions"
> 
> Why us that the process cannot wait for I/O to complete in critical sections?

This is not really a hard requirement. But I guess that you do not want the
CPU to be waiting for IO completion while there are other things it could do.
If you do swapping this means that any access to user space memory can cause
disk access. This is why you should not do user memory accesses either.

> My another question is: While developing kernel modules (for kernels before 2.6), do we need to keep concurrency in mind?
> Because the modules run as part of the kernel and no two processes can run in the kernel at the same time? Or my question is wrong since they CAN run in the kernel at the same time (like when one process waits for I/O completion and another is scheduled to run which then makes a system call)?

When doing development for 2.6 you have to do locking pretty much the same
way when doing multithreaded user space programming. The main difference is
that there is a also locking type called "spinlock", which is needed when
running uninterrupted (e.g. in interrupt handlers). Instead of invoking the
scheduler to run a different task (which cannot be done if you want to run
uninterrupted), it does busy waiting. It hopefully will not have to wait
long: The task which has taken the lock is also running without
interruptions. And tasks which do this have to be quick anyway...

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