This is the mail archive of the
ecos-discuss@sources.redhat.com
mailing list for the eCos project.
Re: interrupts always enabled in scheduler
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