Why the clock interrupt never works in the middle of process?

user_15023994 0
Viewed 229

When jumpint from kernel(RING0) to process(RING1), the clock interrupt never happen however long i wait. But in the middlel of kernel, I use sti and hlt to test clock interrupt then it does happen. I wanna know the reason why the clock interrupt never work in the middle of the process. Thanks in advance.

This is my process code.

#include "type.h"
#include "const.h"
#include "intVector.h"
#include "important.h"
#include "process.h"
#include "prototype.h"
#include "task.h"
#include "global.h"

void delay(){
    for (int i = 0; i < 1; i++) {
        for (int j = 0; j < 10; j++) {
            for (int k = 0; k < 1000; k++) {}
        }
    }
}

PUBLIC void TestA() { //0x05:0x30d01
    int i = 0;
    while (1) {
        dispPos = 0;
        dispStr("A");
        dispInt(i++);
        dispStr(".");
        delay();
    }
}
osdev interrupt x86 assembly c
1 Answers

I don't know how you have concluded that the clock interrupt doesn't happen when you are running a process in user mode, but that's not true. If that where the case, on systems that don't have a hardware timer to allow them to be tickless, there should be no way to regain the control for the kernel in case the process doesn't yield the cpu itself. What is true is that it happens transparently to the user, and can end in a context switch, if there's a process more prioritary and it's time to recalculate priorities.

Of course you cannot inihibit interrupts when you are in user mode, so in my opinion, the only way for you to know that interrupts have occured requires to install some kind of user mode accesible counter for the clock interrupt, and check it at regular intervals, or check for hardware interrupt acknowledges in the bus with a digital signal analyzer.

The clock interupt is normally the shortest to execute and the highest priority one, so thinking that something is impeding it is actually very wierd (normally, this means that only the nmi would interrupt a clock tick, but this normally implies some severe hardware failure ---nmi historically has been associated to parity failures in core memory or to imminent loss of power)

user_38994310
Related