librelist archives

« back to archive

CRITICAL sections a possible cause for interrupt latency

CRITICAL sections a possible cause for interrupt latency

From:
Mathew Swaffield
Date:
2010-12-09 @ 17:45
Hi All,

 

I've been porting atomThreads for use on an MSP430X but I have some concerns
regarding the CRITICAL sections.

 

Currently I've copied what has been done in the existing ports where the
global interrupt flag is disabled and reinstated where necessary.

It seems that there are some large chunks of code and in quite a few places
that are encompassed by the CRITICAL_START and CRITICAL_STOP macros.

This is a concern as it means that any interrupts that come in could have a
potentially unacceptable delay before they are processed (interrupt
latency). 

 

From what I can tell the CRITICAL sections are to protect the moving of the
TCBs from one queue to the next. 

Is there a better way of protecting this or designing out the issue of
protection?

My current thoughts are to change the CRITICAL_START and CRITICAL_STOP to
only mask the scheduler timer interrupt therefore allowing the other
interrupts to be processed, can you see a problem with this?

But I'm also hoping to find a better solution that requires even less
interrupt downtime.

 

Best regards

Mathew

Re: [atomthreads] CRITICAL sections a possible cause for interrupt latency

From:
Kelvin Lawson
Date:
2010-12-15 @ 23:49
Hi Matthew,

Good to hear from you.

> It seems that there are some large chunks of code and in quite a few places
> that are encompassed by the CRITICAL_START and CRITICAL_STOP macros.
>
> This is a concern as it means that any interrupts that come in could have a
> potentially unacceptable delay before they are processed (interrupt
> latency).
>
> From what I can tell the CRITICAL sections are to protect the moving of the
> TCBs from one queue to the next.
>
> Is there a better way of protecting this or designing out the issue of
> protection?
>
> My current thoughts are to change the CRITICAL_START and CRITICAL_STOP to
> only mask the scheduler timer interrupt therefore allowing the other
> interrupts to be processed, can you see a problem with this?
>
> But I’m also hoping to find a better solution that requires even less
> interrupt downtime.

The critical sections allow RTOS structures to be safely modified by
ISRs, for example moving TCBs on to queues as you identified. The
problem with disabling only the timer interrupt is that it would
prevent other (non-timer) ISRs from interacting with the RTOS (for
example incrementing a semaphore to signal from an ISR to a task).

If you want to be able to signal tasks from a non-timer ISR then only
locking out the timer interrupt would not be sufficient. Some RTOS
deal with this using a segmented interrupt architecture, whereby the
RTOS structures are only protected from higher-level ISRs - lower
level ISRs can then run with lower latency but to be able to interact
with the RTOS they must defer to a higher-level ISR. This would reduce
the interrupt latency at the expense of some overhead for ISRs which
must interact the RTOS.

Another option is to reduce the periods during which interrupts are
locked out. This is fairly easy to do from the scheduler point of view
by modifying the kernel scheduler to use a non-queued system such as a
bitmap scheduler, and could be done by modifying only a small portion
of the kernel (in atomkernel.c). However this would not address the
lockouts used to protect non-scheduler RTOS structures, such as queues
used for threads waiting on a semaphore.

I would be interested to hear if users have any thoughts on or
preferences with respect to the segmented interrupt architecture.

Best regards,
Kelvin.