[ECOS] interrupts always enabled in scheduler

[ECOS] interrupts always enabled in scheduler

[Sergei Slobodov]

Hi,

I'm new to this list, sorry if the question has been answered (I did 
search through the archives first, without success).

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?

Please enlighten me!

Regards,
Sergei Slobodov
Caracal Consulting Inc.

Re: [ECOS] interrupts always enabled in scheduler

[Jonathan Larmour]

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
-- 
Red Hat, Rustat House, Clifton Road, Cambridge, UK. Tel: +44 (1223) 271062
Un cheval, pas du glue. Pas du cheval, beaucoup du glue. || Opinions==mine

Re: [ECOS] interrupts always enabled in scheduler

[Sergei Slobodov]

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

Re: [ECOS] interrupts always enabled in scheduler

[Jonathan Larmour]

Sergei Slobodov wrote:
> 
> 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?

What that means is that if you need to resume or suspend a thread, you will
need DSRs. Not everyone needs to do thread operations when they receive
interrupts, so DSRs are an option that can be disabled.

The kernel doesn't know what you want to put in your ISRs. But no matter
what you can't do thread operations from ISRs.

Jifl
-- 
Red Hat, Rustat House, Clifton Road, Cambridge, UK. Tel: +44 (1223) 271062
Un cheval, pas du glue. Pas du cheval, beaucoup du glue. || Opinions==mine