On Sat, Jul 08, 2000 at 09:16:37AM +0100, Stuart Hughes wrote:
> [EMAIL PROTECTED] wrote:
> >
> >
> > This depends on the interrupt and interrupt handler. If the handler
> > calls rtl_Schedule (directly or indirectly) there will be an immediate
> > switch, but if not the switch wil be delayed until the scheduler runs
> > again. So
> > my_isr:
> > pthread_kill(highestprioritythread,RTL_SIG_WAKEUP);
> > return
> >
> > will return to the theard that was running when the interrupt came in,
> > and the resched will happen only during the next run of the scheduler
> > (at the latest, during the next timer interrupt).
> > But
> > my_funny_isr:
> > rtl_wakeup_np(higestprioritythread);
> >
> > will switch at once (unless the thread is on another CPU).
> >
> > Threads are preemptable and RTkernel services are
> > either atomic or preemptable.
> >
> > Hope that answers your question.
> >
>
> Hi Victor,
>
> Is there any way to make it do the following:
>
> lower priority tash runs:
> interrupt occurs and ISR wakes up higher priority task:
> ISR exits
> immediate rt schedule
> higher priority task runs
> higher priority task ends
> lower priority task resumes and completes
>
>
> What I'm after is the re-schedule is pended and set-up to run
> immediately after the iret of the ISR.
We were just discussing that and it is possible to do, but it has
a disadvantage and is not strictly necessary.
First, it's not needed because any ISR can safely cause the same effect
simply by following the design
isr_entry:
finish all hardware related activities
pthread_wakeup_np(highprioritythread);
return;
This is highly efficient and I can't see any cases where it does not
act like your scenario -- except it is faster.
In fact, this can even be made transparent to the ISR writer by
wrapping the ISRs -- I know you don't like extensions to POSIX, but
we are making irq handler installaction go via sigaction and you could
do something in the sigaction field to force an rtl_schedule on return.
So my current thought is that unless there is a flaw in this reasoning
we are ok with a little improved documentation and perhaps a wrapper
accessible via sigaction.
One alternative is a rtl_needs_resched of some sort that is consulted
in rtl_intercept -- at least that's the alternative Michael and I can think
of right now. But I hate to make the intercept code know about the
scheduler and once you introduce SMP things get more complex so ...
And finally, we could do what you suggest, but this makes more arch
dependent and kind of wierd code when I try to see how to do it.
rtl_after_iret_signal:
crawl up stack
find iret return address
copy it to some safe place ; /*watchout for recursion!*/
make it point to rtl_do_after_iret_Signal
return
rtl_do_after_iret_signal
pretend we are in a thread signal handler
call rtl_schedule
rebuild our stack
iret again.
I think that this is not happy code and I dont see it as solving a real
problem.
As always, comments and code are welcome.
>
> Regards, Stuart
>
--
---------------------------------------------------------
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/
