On Fri, Dec 01, 2000 at 06:35:56PM -0700, Gordon McNutt wrote:
> After some thought, I guess I have to agree. However, an interrupt handler
> should be written so that if it calls sem_post() (for example), it should
> expect that an arbitrary amount of time has passed before sem_post returns.
> In fact, the interrupt handler may have been reentered in this interim, since
> it won't return from the sem_post until the task it interrupted gets
> scheduled to run again. This is fine as long as it's written to expect this
> scenario.
Needs better documentation.
>
> >
> > >
> > > My (limited) knowledge of interrupts & schedulers indicates that the
> > > scheduler should just mark the task as ready to run and return. Then,
> >
> > Return to what?
> >
>
> Bad phrasing on my part. The sem_post might mark the target thread as ready
> to run and only call the scheduler if it is not in an interrupt context.
There must be calls to scheduler from interrupt context
in order to have preemptive scheduling.
>
> > > after the interrupt handling code exits, the scheduler is called to pick
> > > the next task to run.
> >
> > Called from where?
>
> Well, in the x86 code, the 'reschedule' label in entry.S, which can be
> reached from the 'ret_from_intr' label in the same file.
Still this is interrupt context.
>
> >
> > There must be some interrupt operation that can force a scheduling
> > or else you have only voluntary preemption.
> >
>
> Sure. But sem_post doesn't have to start running the new task right there, it
> can mark it as ready and return. Rescheduling can occur after the interrupt
> (and any other pending interrupts) have been handled. At least from my
> (admittedly superficial) examination the Linux scheduler and interrupt
> handling seem to work this way.
>
> However, for a real-time system I think that the RT scheduler probably uses a
> better technique... I'll think about it some more over the weekend.
The idea with the RTLinux design is to minimize delay from the moment
a higher priority thread becomes runnable.
>
> Thanks,
>
> --Gordon
--
---------------------------------------------------------
Victor Yodaiken
Finite State Machine Labs: The RTLinux Company.
www.fsmlabs.com www.rtlinux.com
-- [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/
