First of all I don't want to take sides in this hot debate.
I'm interested in merely technial issues.
> 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.
>
> > or:
> >
> > b) enter ISR, wakeup thread, exit ISR, thead code runs.
>
> pthread_kill(thread,RTL_SIG_WAKEUP)
> or
> pthread_mutex_unlock(m);
> executes pthread_kill on all waiting threads.
But _when_ the scheduler will actually start the signalled thread?
Is there any guarantee, that immediately at exit of ISR a rescheduling
occurs?
>
> > I'm saying that b) is more conventional, and I would like to have this
> > facility available.
Personally I think the concept of "interrupt routines are pseudo-threads
with random priority" is not fortunate enough.
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.
OK, I accept the "ISR is a thread" concept.
But why can't I set thread attributes?
These routines might be ordinary threads and its ISR nature
might be just an attribute. pthread_create would not start
them immediately but they wait for the specified IRQ.
If scheduler can start a thread with inherited priority
it would do the same with predefined priority.
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/
