InterruptWait internals

[gopyan]

Hello Friends. My system - Qnx 6.4.0.

Please sched some light on InterruptWait call. I interested in InterruptAttach scheme of interrupt dispatching as you guest.

When Interrupt have occur isr_handler return event that in turn unblock InterruptWait. I'am right??? My question is -> this do immediatly??? Or scheduler simply change the state of interrupt thread (priority , for instance, 10) to RUNNING. If higher priority thread have state RUNNING also??? What happens in this case?????

Thanks.

[maschoen]

Your question is hard to figure out however I'll try.

Interrupts have their own priorities. I don't think this is the issue. The time spent in an interrupt handler is usually and should be very short.

If you do an InterruptWait() after the interrupt returns, your process/thread is set to READY mode. Whether it runs immediately depends as always on priority and competition. If another process at a higher priority is running, you will wait.

The solution is to make order the priority of threads that will wait on interrupts in the order that you want them to run. Real Time means you have control, but you have to decide what is important.

[gopyan]

If you do an InterruptWait() after the interrupt returns, your process/thread is set to READY mode

Sorry , of course, to READY state.

If another process at a higher priority is running, you will wait.

That is I want to understand. Thanks maschoen.

[gopyan]

Maschoen, please say, what is the moment time when thread begin to invoke. In other words, where context switch occur. In interrupt handler??? Or in interrupt handler qnx have change state of the thread to READY and in next time tick thread begin to invoke????

[maschoen]

Maschoen, please say, what is the moment time when thread begin to invoke. In other words, where context switch occur. In interrupt handler??? Or in interrupt handler qnx have change state of the thread to READY and in next time tick thread begin to invoke????

As I understand it, .... All interrupts are vectored to a piece of OS code. The interrupt code knows about processes that have registered interrupt handlers. When an interrupt occurs, the appropriate interrupt handler(s) arc called. After returning, based on the return code, either the interrupt handler wants to trigger an event or not. If not, the OS interrupt code can just allow continuation where the computer left off, there is no reason to re-schedule. If the interrupt handler has requested an event, the OS code must somehow invoke the system scheduler. The scheduler would decide whether a new process is to be run or not based on the usual concern, process priority.

So there is no wait for the next timer tick. This is sometimes known as a pre-emptive scheduler. A process can pre-empt another process when triggered by a hardware event. Without this, QNX would not be hard real-time.