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.
