Gordon McNutt wrote:
>
> Looking at some of the examples, it appears that an RT interrupt handler
> can invoke the RT scheduler (by calling pthread_wakeup_np, sem_post,
> etc). And it looks like the scheduler is going to swap in a runnable
> task when this happens.
>
> This doesn't seem safe... I'm still thinking about it...
>
> My (limited) knowledge of interrupts & schedulers indicates that the
> scheduler should just mark the task as ready to run and return. Then,
> after the interrupt handling code exits, the scheduler is called to pick
> the next task to run.
>
> Is the RTLinux model different, or am I just misreading something?
Have a look at Comer's book on XINU (Prentice Hall) there is a short and
nice explanation on why is safe to schedule from interrupts. That is the
base for all preemptive kernels, and a must for real time RTOSes.
All so called "industrial strength" RTOS manual marks their APIs as
either safe or unsafe for use from interrupt handlers.
The basic law is that you can use whatever API can lead to a reschedule
while keeping the task that is interrupted in the READY state, i.e. a
non blocking schedule.
So you can use sem posts but not sem waits, you can send asynchronous
intertask messages. There is no problem in postponing the task that
posts, for any amount of time, if it happens it is delayed it just means
that there are higher priority things to do, and that's the correct
behaviour.
Clearly it is of utmost important that before calling any nonblocking
rescheduling API you do all what must be done for the hardware, i.e.
acknowledge and enable interrupts on the PIC and reanable interrupt
acceptance on the CPU, or be sure it is done at the end of the
rescheduling operation.
Ciao, Paolo.
-- [rtl] ---
To unsubscribe:
echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR
echo "unsubscribe rtl <Your_email>" | mail [EMAIL PROTECTED]
---
For more information on Real-Time Linux see:
http://www.rtlinux.org/rtlinux/
