0

There are three type of interruptions:

  1. External
  2. Internal (software interrupts)
  3. Syscall (based on internal)

I had got the question "can the interruptions be interrupted or preempted by scheduler (which is also interrupt by timer)?"

After some research i am totally confused:

  • Someone says there are priorities of the interruptions and only interruption with higher priority can interrupt another one. Does it pertain only to external interruptions? / How is it arranged in real OS, say x86-64 Linux? Is it used? / Okay, if some interruption has been interrupted, is it gonna be resumed? Someone says interruptions don't have a "context", but as i know preempting some process / thread occurs with interruptions from a timer, so it's possible to switch context back to the interruption that has occurred to preempt the process. Correct me please if i'm wrong in this.
  • Someone says there is some flag for interrupt handlers "INTERRUPTIBLE", and let's say if some syscall handler is executing with this flag set it may be interrupted by a signal. Is it related only to software interruptions? Don't external interruptions have that flag? / What if this flag is not set but the timer (for example) interruption occurs to preempt the thread? Is it ignored?
  • Someone says it only depends on what an interruption handler is doing. For example if there is read() syscall that is waiting for input, it sets particular flags so that scheduler (timer interruption) can interrupt and preempt it. But if the handler is doing something crucial it can forbid to interrupt or preempt it, so it's gonna possess a cpu by itself until it finished. It seems there are a lot of mechanisms in x86, and i don't absolutely get which one is used and how it works in real life.
Rost
  • 65
  • 1
  • 7
  • 1
    While it is true that there are different kinds of "interruptions", a syscall is definitely not one of those. A syscall is simply a task entering kernel space to run kernel code and extract the needed information from the system, it doesn't really "interrupt" anything. – Marco Bonelli Apr 23 '20 at 11:14
  • 2
    Any time the kernel knows it needs to block, it calls `schedule()`. e.g. a read system call finds that a necessary page is on disk, not in the pagecache, is will call functions to begin the I/O, but then instead of busy-waiting for the I/O it sets things up so this task will be woken by the scheduler when the page is ready. This is *not* preemption, this is voluntary scheduling of another task. – Peter Cordes Apr 23 '20 at 11:16
  • 1
    @MarcoBonelli: the legacy way to use the 32-bit system-call ABI is the `int 0x80` instruction. That is typically *called* a software interrupt, but yeah, it's synchronous, not asynchronous. (Fun fact: it still works the same even if interrupts were disabled.) So I understand why the OP used that confusing terminology. (System calls and so on are more like synchronous exceptions, like a page fault. [What happens to software interrupts in the pipeline?](https://stackoverflow.com/q/54427842) covers the CPU architecture details, but not software / OS details) – Peter Cordes Apr 23 '20 at 11:20
  • @PeterCordes, okay thanks, it clarified something. But i still don't get what is happening in these two cases for example: 1. will syscall handler be interrupted and preempted by a timer (scheduler) if the handler has consumed its quantum of time? 2. the same case but with external interruption instead of syscall? – Rost Apr 23 '20 at 11:30
  • 1
    Yes, most kernel code can be pre-empted. True IRQ-handlers (what Linux calls "top half" handlers) may not be interruptible, or at least not pre-emptible (if a nested IRQ-handler runs, it needs to return directly, not schedule something else). – Peter Cordes Apr 23 '20 at 11:36

1 Answers1

2

(Answering for Linux on x86, since those are your tags).

There are only two types of events that could interrupt your code. Interrupts, and exceptions. Syscalls are considered exceptions.

I had got the question "can the interruptions be interrupted or preempted by scheduler (which is also interrupt by timer)?"

The scheduler doesn't interrupt anything. It's just code, it doesn't run on it's own. Only an interrupt or exception can interrupt your code. You can have a timer interrupt occur that then calls the schedule().

If you're in an interrupt, interrupts are likely disabled. So no timer interrupt, thus no schedule(). If you're in an interrupt with interrupts enabled (allowing for nested interrupts), a timer interrupt could try to invoke the scheduler, but it wouldn't run because it would detect that preemption is disabled. And preemption is always disabled when you're in an interrupt via the preempt_count field. The goal here is to prevent preemption in an interrupt context.

You have lots of other questions, but most of them can be answered by reading the available literature on the subject.

Matviy Kotoniy
  • 362
  • 1
  • 13