Questions about preemption and concurrency

Questions about preemption and concurrency

[Naman shekhar Mishra]

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. 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?
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)?


Please excuse me for the multiple nested question since I didn't quite know how to put it.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20110527/c67ed548/attachment-0001.html 

Questions about preemption and concurrency

[Daniel Baluta]

On Fri, May 27, 2011 at 2:44 PM, Naman shekhar Mishra
<namanshekharmishra2@yahoo.in> 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. The only requirement is that critical
> sections do not contain references to user memory
> or waits for I/O completions"

This is available only if the kernel is non-preemptive. If the kernel is
preemptive than a process executing in kernel, can be preempted
by another process.


> Why us that the process cannot wait for I/O to complete in critical
> sections?

Because deadlocks may sneak in ([1]).

> My another question is: While developing kernel modules (for kernels before
> 2.6), do we need to keep concurrency in mind?

I guess yes. Even if the kernel is non-preemptive, you may want to consider SMP.

> 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)?
>
> Please excuse me for the multiple nested question since I didn't quite know
> how to put it.

HTH,
Daniel.

[1] https://lwn.net/Articles/274695/

Questions about preemption and concurrency

[Jonathan Neuschäfer]

On Fri, May 27, 2011 at 05:14:51PM +0530, Naman shekhar Mishra wrote:
> 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)?

I'm not sure what "run in the kernel" means here, but there can
definetely be more than one process waiting in a system call (e.g.
in a read() on a tty). IIUC, almost any "sleeping" process is.

Processes that wait for disk IO are in "uninterruptible" state which
also allows other processes to run and do system calls.

On SMP systems, where code is really run in parallel, certain resources
and code paths (e.g. ioctl, some file systems), used to be protected by
the Big Kernel Lock, which has just recently been removed.

HTH,
	Jonathan Neusch?fer

Questions about preemption and concurrency

[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