Процесс, ограниченный по времени, помогите советом Опции

[_Pasha]

Доброго времени!
Требуется соорудить такую конструкцию:
предположим, у нас выполняется некий процесс. Считаем что-то, короче.
По наступлению прерывания от таймера необходимо из этого процесса выйти, да так, чтобы запомнить его состояние и впоследствии вернуться и продолжить его выполнение.
На ассемблере это делается элементарно.
Проблема в реализации этой конструкции на C - мешает нереентерабельность функций, огромные сохраняемые контексты.
Пока что представляю, как это сделать в рамках main() - с помощью setjump() и такой-то матери.
Как это сделать в любой другой функции - как эти функции заточить по правильному - не имею понятия.
В идеале хочу выйти на что-то типа

Код

TIME_LIMITED_BLOCK(T_100us)
{/*code*/
}

взяв за основу for() как ATOMIC_BLOCK в WINAVR.

В общем,если есть какие-то советы, милости просим.

[sensor_ua]

Дык надо volatile объявить. Рубиться не должно.

Объявлял. Чего-то версии 071221 было не так ещё. С тех пор к программингу AVR на WinAVR не получалось прикасаться.

Неудобно в сложных автоматах. Как обстоят дела в этом случае?

Для взаимоувязанных дискретных выходов офромляю "программные генераторы", обслуживающие пины в жестком риалтайме (в обработчике прерываний таймера), а задания для них формирую в фоне. Что касается вариантов с разрешением порядком 1 мс, то плавание этой 1-й мс в диапазоне, например, 0... +20 мкс (минуса НИКОГДА не будет) часто никак не сказывается на реальном оборудовании и реальных системах в разумных оценках. Как пример - управляю быстрым клапаном, для которого 1 мс это гарантированное минимальное время открывания (с хорошим запасом для учета воздействий температуры, состава носителя, износа и пр.) - дык производительность системы не страдает (ну не заметно этого никак и ничем). Грубо - ну будет в среднем ошибка +10 мкс - соотнесём это с разной шероховатостью кромок всяких железочек там, неточностью диаметра отверстия от экземпляра к экземпляру и разной вязкостью носителя в разное время, зависящее от погоды в Ханты-Мансийске - в общей погрешности погрешность времени срабатывания окажется ничтожно малой, и это с учётом того, что взят худший случай - минимальное время импульса открывания.
Если рассматривать возможные ошибки между параллельными во времени автоматами, то даже с использованием прерываний абсолютную параллельность на одном процессорном ядре никак не получить, а при мягком риалтайме сетка времени обычно выбирается одна для разных параллельных процессов. Конечно если возникает необходимость в разрешении взаимно-зависимых временных коллизий, то тут нужно определиться - насколько количество таких завязок велико и решать либо вопросы взаимоблокировок по месту, либо строить общий программный механизм, рулящий приоритетами обслуживания временнЫх событий. Не буду пытаться всё обозвать правильными терминами - там, напрмер, кое-чего есть http://george-sergeev.by.ru/osch4.html
И ещё - вспоминается POSIX 1003.1b - http://qnx.org.ru/article11.html - ведь ОС вааще не знает об алгоритмических зависимостях между процессами (грубо - каждое ядро занято своим процессом - как им объяснить, что кто-то главнее? - приоритеты, но приоритеты - палка о двух концах, потому если есть возможность их - разноуровневые - не употреблять, то лучше и не встрявать; и ими ещё надо не только пользоваться, но и уметь рулить в конкретной системе).