On Fri, Jun 23, 2000 at 02:20:21PM +0200, [EMAIL PROTECTED] wrote:
> 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?
No. It's an easy fix and I think we should add it.
> > > 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
No. The signal handler runs outside the priority system entirely, but
the thread that was interrupted is still the current thread and the ISR
runs on the stack (in the context) of the interrupted thread.
Where things become somewhat peculiar is when an ISR calls the scheduler
(possibly indirectly). The scheduler may then decide to change contexts
to that of a thread with priority higher than the existing thread so we
can have
thread A is running
interrupt
ISR call sched
switch to Thread B
exit B to scheduler
switch back to A
ISR returns !
> 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.
I don't like ISRs as threads. ISRs are more lightweight than threads and
should be absolutely minimal in terms of state.
> 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/
--
---------------------------------------------------------
Victor Yodaiken
FSMLabs: www.fsmlabs.com www.rtlinux.com
FSMLabs is a servicemark and a service of
VJY Associates L.L.C, New Mexico.
-- [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/
