OSDev.org

I think a preemptive kernel would be very useful for the multiprocessing to kill the deadlocks.
What do you think about this?

Have you any idea about implementing this?

I'd say no. As the kernel might be working on more places which increases the chance that a deadlock occurs.
Although the chance a deadlock locks up the kernel is lower, but data might be inconsistent.

There are no real disadvantages to having a preemptible kernel, apart from coding time and effort. Whether you actually preempt in the kernel is another matter - linux for example provides a config switch so that you can choose.

JamesM wrote:preemptible kernel

http://en.wikipedia.org/wiki/Preemptive_multitasking wrote:Some modern systems have preemptive kernels

However, how can I implement preemption in the kernel?

To do preemption in the kernel just don't do anything to prevent it. So on a system call don't disable interrupts and make sure your scheduler doesn't distinguish between kernel mode and user mode when scheduling threads.

thooot wrote:To do preemption in the kernel just don't do anything to prevent it. So on a system call don't disable interrupts and make sure your scheduler doesn't distinguish between kernel mode and user mode when scheduling threads.

Are there anything to do related to security?

Jeko wrote:

JamesM wrote:preemptible kernel

http://en.wikipedia.org/wiki/Preemptive_multitasking wrote:Some modern systems have preemptive kernels

What's your point? "preemptible" means the kernel is designed to be able to be preempted. "preemptive" means the preemption is enabled. It can be preemptible without being preemptive.

Jeko wrote:Are there anything to do related to security?

Not that I'm aware of. You do need to watch out for places where you don't want to be preempted though (such as when you're holding a spinlock).

JamesM wrote:

Jeko wrote:

JamesM wrote:preemptible kernel

http://en.wikipedia.org/wiki/Preemptive_multitasking wrote:Some modern systems have preemptive kernels

What's your point? "preemptible" means the kernel is designed to be able to be preempted. "preemptive" means the preemption is enabled. It can be preemptible without being preemptive.

Ah...Sorry

thooot wrote:Not that I'm aware of. You do need to watch out for places where you don't want to be preempted though (such as when you're holding a spinlock).

So a preemptive kernel is a normal kernel with multitasking enabled?

It's not necessarily good to enable preemption in most parts of the kernel. Imagine a microkernel that has very fast system calls. All the work is done by user space application. When a user space process calls a write() system call (of course I'm talking about non-blocking system calls here) in order to write some bytes to a pipe (or message box) the kernel generally has to acquire a spinlock or semaphore before it can modify the pipe's buffer. If the kernel is interrupted before releasing the lock it might switch to another processes that also tries to access the pipe. The second process has to wait until the first process finishes its write() operation. Now imagine that many processes that access a single (kernel-) resource that is currently locked by another process. If preemption was disabled for the write() system call throughput would be greatly improved (at least for all threads on the same processor). It's not always good to enable preemption for every system call; especially for system calls that are very fast and have a constant worst-case running time. write()ing to a pipe is usually O(size_of_pipe_buffer) with very small constants. Even if write() is not preemptive interrupts will still be processed without any significant delay.