View topic - InterruptWait internals
InterruptWait internals
5 posts
• Page 1 of 1
InterruptWait internals
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.
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.
- gopyan
- Active Member
- Posts: 64
- Joined: Tue Mar 02, 2010 1:39 pm
Re: InterruptWait internals
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.
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.
- maschoen
- QNX Master
- Posts: 2728
- Joined: Wed Jun 25, 2003 5:18 pm
Re: InterruptWait internals
maschoen wrote:If you do an InterruptWait() after the interrupt returns, your process/thread is set to READY mode
Sorry , of course, to READY state.
maschoen wrote:If another process at a higher priority is running, you will wait.
That is I want to understand. Thanks maschoen.
- gopyan
- Active Member
- Posts: 64
- Joined: Tue Mar 02, 2010 1:39 pm
Re: InterruptWait internals
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????
- gopyan
- Active Member
- Posts: 64
- Joined: Tue Mar 02, 2010 1:39 pm
Re: InterruptWait internals
gopyan wrote: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.
- maschoen
- QNX Master
- Posts: 2728
- Joined: Wed Jun 25, 2003 5:18 pm
5 posts
• Page 1 of 1
Who is online
Users browsing this forum: No registered users and 2 guests