> > Personally I think the concept of "interrupt routines are pseudo-threads
> > with random priority" is not fortunate enough.
I mean the _current_ concept.
> >
> > Did I misunderstand something? AFAIK when an interrupt occurs
> > its handler is started as an implicit thread inheriting its priority
> > from the interrupted thread. The most possible interrupted thread is
> > the the Linux itself which has minus infinite priority. That means
> > that an ISR will run probably the lowest priority.
> >
>
> No, this is not a good assumption. Classically, an interrupt handler has
Not good, but better than the current.
> a *hardware* priority, this is unrelated to the concept of the priority
> of threads. Usually, when an interrupt occurs, it interrrupts whatever
> is running provided that a) interrupts are enabled, b) if currently in
> an ISR, the hardware priority of the new interrupt is higher than the
> current interrupt priority (implementation is architecture dependant).
This is your wish or the reality? ;-)
We were speaking so far, that ISRs run long because threads awaken
by them grabs the CPU.
Now I have such an ISR. There can be occur such a situation,
that it runs in two instances because the first one is delayed
by a high priority thread, meanwhile the hardware IRQ is delivered
again.
Remember what Victor wrote:
| You have a choice.
|
| >
| > a) enter ISR, wakeup thread, thread code runs, return to ISR, exit ISR
| >
|
| pthread_wakeup_np(thread)
| if "thread" is higher priority than the current thread, whatever
| it may be, then we switch and run the thread, and return to this
| thread later and then exit the ISR.
|
I repeat: "current thread" is generally has extreme low priority.
(I.e. usually this is the Linux.) Therefore any other thread (waken up by ISR)
will run sooner than ISR could exit.
When I say ISR I mean the handler installed by rtl_request_irq().
Regards
Gabor
-- [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/
