On Fri, 2004-03-19 at 19:28, Eric BEGOT wrote: > Hi all. Hi, > I've some questions about the Linux kernel. > We say that Linux is reentrant but not preemptive (until 2.6.x). That > means that the code can be executed by two "processes" (threads I should > say becoz we're in Kernel mode) in the same time but that a process > cannot be interrupted by another. Am I rigth here ?:) Right, before 2.5 a code in the kernel could not be _involuntarily_ interrupted by other code, except interrupt handlers and softirqs. (Another way to say this is that before 2.5, process context code could not preempt other process context code while it was in the kernel). > But if the kernel is non preemptive and that we're not using multiple > processors, this means that multiple "processes" cannot be executed in > the same time, no ? > So, if Linux is a pure non preemptive kernel, non reentrance doesn't > affect the Kernel (except for SMP)? The missing bit is voluntary preemption and nested interrupts. Aisde from these issues, however, you are right that concurrency does not occur sans SMP and kernel preemption. Couple examples... Let's take a function foo(). While in foo(), say process A blocks (by manually calling schedule() or whatever). Process B can now enter foo() and everything is safe. Thus foo() is reentrant. Alternatively, foo() can be a function used by interrupt handlers. If process A is in foo(), an interrupt occurs, the interrupt handler calls foo(), and everything is fine, then we say that foo() is reentrant. In general, I think the term reentrant is pretty vague and therefore worthless. For example, a lot of times it is _not_ safe to reenter a function while another function is inside. So we use locks or disable interrupts or whatever to prevent that. But people still tend to call said function reentrant. So really reentrant just means safe, by some means (which may be becomes the function could never be called concurrently to begin with). > Another point is the non preemptivity of the kernel. In the book I'm > reading (Undertsand Linux Kernel from Oreilly), they say that > interruptiosn can be nested. So, an interruption can interrupt the > current "process". So the Linux kernel is "preemptive" ? Not really in the sense you are describing. Calling a kernel preemptive tends to mean that arbitrary process code can interrupt other arbitrary process code (what you call "threads") at will. This can occur in 2.5 and later, but no earlier. Allowing interrupts to nest is unrelated, although it is merely a matter of definition. > Finally, I'd like to know if on preemptive kernel, kernel threads can be > interrupted by user processes. Yup. In fact, that is the primary difference - code in the kernel can be preempted in preference of other code, which is often user code. Hope I helped, some! Robert Love -- Kernelnewbies: Help each other learn about the Linux kernel. Archive: http://mail.nl.linux.org/kernelnewbies/ FAQ: http://kernelnewbies.org/faq/
