Хм. И по спискам задач (семафоров, мутексов и т.д.) под запрещенными прерываниями не ходите?

Мда, поторопился я ответить. Прямой зависимости от количества задач нет, но, действительно, критические секции добавляют задержку: если говорить про мютексы, то чем больше задач одновременно ожидают мютекс, тем больше времени требуется, чтобы определить приоритет той задачи, которая захватила этот мютекс. Вы правы.

Другое дело, что на некоторых платформах (пока только dsPIC/PIC24) есть возможность запрещать в критических секциях не все прерывания, а только определенный диапазон приоритетов прерываний. Но тогда из остальных прерываний нельзя вызывать сервисы ядра.

Во! Значиццо есть куда стремиться. Поскольку мутексы (по логике вещей) не используются из прерываний, логично было бы обойтись без критических секций в данном случае.

Эта фишка во FreeRTOS тоже искаропки идет, как минимум на ARM Cortex-M3 и Renesas RX. Но описанные минусы напрягают.

Вам нужен AVIX тогда. http://avix-rt.com/ Она никогда не запрещает прерывания, вообще. Но денег стоит.

Это наверно оверкилл, хотя давно у меня чешется что-нить подобное наваять (естественно на архитектурах, где такое вообще возможно). Но речь здесь о TNeo vs FreeRTOS. Так вот, FreeRTOS под запрещенными прерываниями списки не обходит. Отсюда и "большие задержки".

Хм. Насчет мютексов примерно ясно: действительно, можно запрещать только планировщик, а не все прерывания, т.к. мютексы в прерываниях не используются. Ок, но как, например, с таймерами? Если запущено много таймеров, то эту очередь надо как-то обслуживать, и чем больше таймеров в очереди, тем больше времени это занимает.

Ладно, спасибо за инфу, когда будет время, попробую разобраться.

Это один из вариантов. Можно еще:
1) хранить список ожидающих задач в отсортированном виде.
2) запрещать прерывания только на время работы с конкретным элементом

Логично. Поэтому таймеры в виде коллбэков из прерывания - зло.