A quick question for those in the know here.
I have been reading my OS book trying to figure something out. When a CLI instruction is executed all maskable interrupts are disabled until the next STI, yes?
Are the interrupts held back or blocked. I.e. if a timer interrupt would have occured when interrupts are disabled does it cause an interrupt as soon as STI is executed?
Basically put, if I disable interrupts, will it stop hardware/software interrupts but not actually miss them?
CLI/STI
Re:CLI/STI
I think you'll find it doesn't so much as stop them happening as stop them being seen so to speak.
Basically it masks the interrupts which means it makes it so that when one occurs it doesn't actually register. its kind of like having a headache or extreme pain of some sort when you take some pain killers you no longer feel the pain. But the signals for the pain are still being sent so you effectively lose those pain signals the same is true for the interupts.
This is why it is recommended any operation ocurring while interupts are off is fast.
Peter
Basically it masks the interrupts which means it makes it so that when one occurs it doesn't actually register. its kind of like having a headache or extreme pain of some sort when you take some pain killers you no longer feel the pain. But the signals for the pain are still being sent so you effectively lose those pain signals the same is true for the interupts.
This is why it is recommended any operation ocurring while interupts are off is fast.
Peter
- Pype.Clicker
- Member
- Posts: 5964
- Joined: Wed Oct 18, 2006 2:31 am
- Location: In a galaxy, far, far away
- Contact:
Re:CLI/STI
when interrupts are blocked (with a CLI), any hardware Interrupt ReQuest will be kept on the Programable Interrupt Controller (or its Advanced version : the APIC) so that when you STI, the interrupt is delivered (but with a little delay).
This means that relying on the timer interrupt to keep your clock on time will not be slowly drift...
But watch out! the PIC only remembers ONE interrupt request. If you block the interrupts for so long that 2 IRQ for the same device are risen up, then you will be interrupted only once ... which may trouble you while reading the keyboard, for instance (you'll have a scancode pending that you won't be able to deliver).
This means that relying on the timer interrupt to keep your clock on time will not be slowly drift...
But watch out! the PIC only remembers ONE interrupt request. If you block the interrupts for so long that 2 IRQ for the same device are risen up, then you will be interrupted only once ... which may trouble you while reading the keyboard, for instance (you'll have a scancode pending that you won't be able to deliver).
Re:CLI/STI
Thanks all, thats what I suspected, but wasn't sure. I didn't realise it will only hold one IRQ in queue though, that shouldn't be a problem though for what I have in mind.
I think I might try and work in a system of delayed interrupts rather than blocking entirely. I.e. if a timer interrupt occurs the kernel will make a note of it and then execute it when the kernel leaves a critical section.
PS. If anyone is interested I have posted up the latest version of my test code on my website it anyone wants to have a look to help them with thier own code. Its far from complete but does do software task switching, IDT setting up and interrupt handling and has some code for handling modules/memory and the like.
http://homepage.ntlworld.com/daryl.dudey
I think I might try and work in a system of delayed interrupts rather than blocking entirely. I.e. if a timer interrupt occurs the kernel will make a note of it and then execute it when the kernel leaves a critical section.
PS. If anyone is interested I have posted up the latest version of my test code on my website it anyone wants to have a look to help them with thier own code. Its far from complete but does do software task switching, IDT setting up and interrupt handling and has some code for handling modules/memory and the like.
http://homepage.ntlworld.com/daryl.dudey
- Pype.Clicker
- Member
- Posts: 5964
- Joined: Wed Oct 18, 2006 2:31 am
- Location: In a galaxy, far, far away
- Contact:
Re:CLI/STI
i personally use CLI/STI for the smallest possible amount of time (i.e. while accessing a semaphore, for instance: clicker CLI before it starts checking if the semaphore is available so that the current thread don't get preempted between the time it sees the semaphore isn't free and the time it has put itself in the wait queue...)