Re: Why can't we sleep in an ISR?

["pradeep singh" <2500.pradeep@xxxxxxxxx>]

On 5/14/07, Learning Linux <learninglinux4@xxxxxxxxx> wrote:

> >> On the other hand, when you sleep in a given context, the scheduler is
> >> invoked. That means that the ISR routine would be replaced by a process
> >> from the scheduler's queue(s). But how would you ever know to reschedule
> >> the ISR? After all, it is asynchronous.
> >
> > Uh, this is what I have my doubt about. Yes, the scheduler may try to
> > replace the current process (already interrupted by the ISR) with
> > another process.
> >
> > So, what is the problem with that? Could you please elaborate on the
> > part "how would you ever know to reschedule the ISR? After all, it is
> > asynchronous"?
>
> Well, the ISR code has to be resumed at some point doesn't it? How would
> you know how to "get back" at executing it? There's no ISR scheduling
> queue, as there is no process. An ISR can interrupt any given process
> (that's what I meant by asynchronous).

Yes. The ISR can interrupt any process. But the scheduler is totally
unaware of it (CMIIW). As far as scheduler is concerned, it thinks
that the processor is still executing the code of the process that ISR
interrupted. In fact, all the time ISR executes is deducted from the
timeslice of the process that was interrupted.

Yeah, what then if an ISR takes more than the remaining time left for current 
running process's share?How will scheduler account for this?Because techincally process has over run its time slice.Isn't it?

Assuming the simple case of 8KB stacks (ISRs share the process stack).
So the scheduler can still perform a context switch saving and
restoring the save of the process it THINKS is currently executing
(The PC will actually point to an address in ISR) and later on restore
from where it left?

--
To unsubscribe from this list: send an email with
"unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx
Please read the FAQ at http://kernelnewbies.org/FAQ

-- 
play the game