Re: [ECOS] interrupts always enabled in scheduler

[Sergei Slobodov <sergei at slobodov dot com>]

Thanks! That makes sense. I assumed that since the config tool allows 
configuration with kernel but without DSRs, eCos ISR is allowed to 
resume or suspend a thread directly, without resorting to DSR. If this 
assumption is wrong, why is  including kernel without DSR support not  
flagged as a configuration conflict?

Thanks,
Sergei Slobodov
Caracal Consulting Inc.

Jonathan Larmour wrote:

> Sergei Slobodov wrote:
> 
>> I'm looking through the sources, trying to determine whether we should
>> try to use ecos or port our own kernel from another platform, and there
>> is at least one major issue I don't understand. ECOS seems to support
>> nested interrupts, yet there is no interrupt enable/disable pair around
>> the code that manipulates thread queues, such as Cyg_Thread::resume(),
>> which non-atomically changes global scheduler structures. Woudn't it
>> cause data corruption if a higher priority interrupt occurs in the
>> middle of resume() call?
> 
> 
> eCos has been designed to disable interrupts as infrequently as possible.
> No interrupt handler (ISR) will change the thread queues directly. The only
> protection needed is that provided by the scheduler lock ( which is locked
> using Cyg_Scheduler::lock()) which prevents pre-emption by other threads,
> _and_ pre-emption by a deferred service routine (DSR) which is the portion
> of the interrupt handling system which *is* allowed to change the thread
> queues. Only one DSR runs at a time, and these are scheduled outside of
> threads, i.e. no threads run while a DSR runs.
> 
> Jifl