Ther are two possibilities that occur to me:
1) pthread_delayed_reseched something that won't annoy Stuart
that does
run the scheduler to see if a higher priority thread is ready
and to force a resched when any ISR exits, if this is true.
e.g.
isr does
pthread_kill
pthread_delayed_resched
2) Implement the Pthreads "execute the signal handler as a thread"
idea.
On Fri, Jun 23, 2000 at 04:47:01PM +0200, [EMAIL PROTECTED] wrote:
> > > 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/
--
---------------------------------------------------------
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/
