Heinz,
I'll only speak for the uniprocessor case, as I really have no clue
as to what happens in the multi-processor case.
> I guess whenever an ISR is running, no regular (RT)task could be
> active? So there shouldn't be a way an ISR could be 'interrupted' by a
> regular process. Am I right?
This is true (sort of). The ISR runs in the context of whatever
thread had the CPU when the interrupt was generated. If the ISR *chooses*
to allow the scheduler to do its thing: by calling pthread_wakeup_np, for
example, then the task (and thus the ISR) may get pre-empted. Thus the ISR
will not complete until the other task returns the CPU and the task the ISR
had interrupted gets rescheduled. Then the ISR will complete.
This is why it is vitally important to complete all of our hardware
wrangling in the ISR before doing anything that causes the scheduler to be
called.
It is important to note that when the scheduler does the pthread
swap, the interrupt state, etc. is restored/saved. Thus the machine is able
to accept new interrupts while the other process is running. You are not in
a perpetually interrupted state until the first ISR completes. Thus the
fact that the system will make a brief trip back through the ISR to hit the
IRET before continuing with the original task is of little consequence.
Regards,
Steve
P.S. I hope Victor or Michael will jump in here if I say something
incorrect...
-- [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/
