5

I just reading an article which says:

Reasons to control the interrupt system generally boil down to needing to provide synchronization. By disabling interrupts, you can guarantee that an interrupt handler will not preempt your current code. Moreover, disabling interrupts also disables kernel preemption. Neither disabling interrupt delivery nor disabling kernel preemption provides any protection from concurrent access from another processor,however.

So I just wonder the difference between interrupt and kernel preemption.

Or could we say disabling kernel preemption also disables interrupts?

sliter
  • 1,063
  • 1
  • 17
  • 34

2 Answers2

16

When a process is interrupted, the kernel runs some code, which may not be related to what the process does.
When this is done, two things can happen:
1. The same process will get the CPU again.
2. A different process will get the CPU. The current process was preempted.

So preemption will only happen after an interrupt, but an interrupt doesn't always cause preemption.

ugoren
  • 16,023
  • 3
  • 35
  • 65
2

They're different. Interrupts may occur outside even the context of the kernel, so changing the way the kernel handles preemption won't affect interrupts. It just appears that in the context of your article, kernel preemption depends on interrupts working (probably because it's implemented using a timer of some sort).

Carl Norum
  • 219,201
  • 40
  • 422
  • 469
  • Hi, Carl, thanks for your answer. Can you give me an example in Linux where interrupts occurs outside the context of the kernel? – sliter Feb 28 '12 at 09:22
  • That's pretty system dependent. I think @ugoren's answer explains the concept pretty well. – Carl Norum Feb 28 '12 at 16:05