Is it possible to use Ipipe like constructions with QNX? Ipipe is like a pipe where in interrupt propagates in, each process that listens to the pipe gets a notice of the interrupt in a predetermined manner. This would allow to have different processes listen to the same IRQ; but not knowing that some other process already did something with that particular IRQ. While the IRQ is handled by a process; the pipe gets ‘stalled’, and has to unstal the IRQ before it will propagate any further.
The reason for all of this, is for instance if I have a periodic task thats needs to run at 1000Khz, (0.01 ms) I can set the system clock a little faster, and get the timer resolution that is required. The micro kernel would also run on a higher frequencies; but if there is some ipipe like construction, I could let it wait for 10 events before it actually runs.
Is this just plane stupid? RTAI uses adeos (nano kernel) to deliver the ipipe like construct, I do think when doing periodic tasks, this might be very handy.
That might be possible if you customize the startup module. Or simpler, get a timer card that generated its own interrupt.
It might be possible also if you make sure your interrupt handler is at the top of the list (the one that registered first) and upon reception of the interrupt you clear the interrupt at the hardware level. That means when the kernel interrupt for the timer is invoked it will look at the hardware to make sure the interrupt is from the timer hardware but will think it was and won’t do anything about it. I’m making the assumption the kernel timer interrupt makes such a check, one would have to look at the source code to make sure.
About the ipipe thing, it’s dangerous because if the interrupt is shared with multiple hardware ipipe can’t know about it and may end up NOT invoking the proper ISR and freezing the machine.
On x86 hardware, the IRQ numbers are handeld by order right? So IRQ0 goes before IRQ5.
As such using an external IRQ while IRQ0 is being handeld, would give unpredictable results would it not? So is adapting the startup module such a bad idea?
Is the timer intterupt not sending pulses to the ‘rest’ of the kernel then? Just like other interrupts?
With the clockTime() functions I’m able to set the 1ms timer interval to 0.1 ms. Other threads on this forum suggest that this is not a good idea; since the OS will create extra overhead due to the extra scheduling etc.
But what If i want to have just one specific thread to be scheduled @ 0.1ms interval and the ‘rest’ of the operating system @ 1ms I.e adjust the clock for one specific thread?
It may or may no be a good idea it all depends on what your requirement are. I mean in that same line of though the default 1ms may be too much for certain system.
You cannot have one thread a .1ms and the os timer set at 1ms, it doesn’t make sense in the big scheme of thing. You can do interrupts at .1ms but you can’t have os services (timer/delay) be more precise then OS timer.
You can’t do this (sort of makes the next point gratuitous)
Even if you could, this wouldn’t reduce the overhead, since the overhead comes from the system clock handler, not from scheduling other threads. The clock handler will be invoked in either case.
The real-time clock is your best bet if you are on a PC, as this does what you want to do (only have one piece of work done on each tick, without dragging in the system clock handler and everything that it does).
