This is the mail archive of the ecos-discuss@sources.redhat.com mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: nested interrupts



> > 
> > One more question. By looking into the source code, I still can't
> > figure out that why DSRs can call most kernel functions but
> > ISRs can't. Is it the stack problem or scheduler locking problem
> > or something else?
> 
> The kernel does not block interrupts during critical sections, so an
> ISR can occur at any point, even while the scheduler is manipulating
> the run queues. If the ISR then tries to manipulate the same data
> structures, by calling a kernel function, then they will be
> corrupted. Hence the use of DSRs to defer these calls until the data
> structures are in a consistent state.
> 
> 
> -- 
> Nick Garnett, eCos Kernel Architect
> Red Hat, Cambridge, UK

Thanks for your explanation. But I still got confused.
As described by Gary Thomas in
http://sources.redhat.com/ecos/docs-latest/porting/hal-interrupts.html

> The way it is supposed to work is like this (pseudo-code to abstract
> machine details):
>
> VSR:
>   mask interrupts (if necessary)
>   save interrupt context on thread stack 
>   lock scheduler
>   switch to interrupt stack (if defined)
>   call ISR
>   switch back to thread stack
>   call interrupt_end
>   restore interrupt context from thread stack
>   exit VSR
> 
> Note: interrupt_end called with interrupts disabled, scheduler locked
> 
> interrupt_end:
>   possibly schedule a DSR, based on paramters from VSR
>   drop scheduler lock  
>   if scheduling enabled, run pending DSRs (actually just part of scheduling)
>   note: interrupts are still disabled when entered from VSR
> 
> hal_interrupt_stack_call_pending_DSRs:
>   [disable interrupts (may be moot)]
>   switch to interrupt stack
>   enable interrupts
>   run DSRs
>   disable interrupts
>   switch back to thread stack
>   restore interrupts

Which step above does indeed make the kernel state safe to be called by DSRs?

For example, an interrupt occurred while a thread is running in scheduler's critical
section. It's not safe to manipulate scheduler's data in ISR obviously, but it seems
also not safe to access scheduler's data in DSR since the interrupted thread still
doesn't finish its job to make the data consistent. Am I wrong here?

Thanks.



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]