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