Я же все объяснил на конкретном примере.
Еще раз, но на пальцах:
Пусть IrState.ctim10ms равно, скажем 10, но прерывание еще не возникло и в этот момент выполняется в задаче это кусок:
IrState.ctim10ms = IrState.bRxTx[pValue->nComm][0];
скажем нас прервали как раз перед записью нового значения в IrState.ctim10ms, собирались записать туда 100, которые тока что вычитали из IrState.bRxTx[pValue->nComm][0]
и тут вдруг возникает прерывание, где мы вполняем эту строчку:
if(IrState.ctim10ms) IrState.ctim10ms--;
логично, что после выхода из прерывания будет IrState.ctim10ms = 9,
а тут мы выходим из прерывания и тут же загоняем в IrState.ctim10ms = 100
Не знаю, как это скажется на логике работы прерывания, но явно, что в следующем вызове прерывания вместо 9 вдруг получить 100 - очень странно.
Как себя поведет прога в таком случае остается только гадать....

Цитата
К тому же как я понимаю: указанный участок внутри таска начнёт выполняться только когда IrState.ctim10ms == 0.
Ну-ну. Но чуть-чуть поменяли логику и привет? Ловим баги на ровном месте, через час/сутки/год? Тут кому как повезет.
Существуют неписанные правила: доступ к глобальным объектам при чтении-модификации-записи (из задачи) должен быть защищен от любых прерываний, которые могут этот объект изменить посреди этой цепочки.
Для таких случае в простейшем варианте можно использовать критическую секцию.
А в идеале - вообще избегать "дергать" один и тот же глобальный объект из задачи и прерываний. Есть решения.
К тому же нужно постоянно держать в голове - "а что будет, если ... ". Кому нужна доп. головная боль на ровном месте?
В той же MISRA вообще рекомендуют избегать или на край очень осторожно использовать глобальные объекты.
Разумеется, если используются прерывания. Но где их нынче не используют?