|
|
Если у вас вход-выход жОстко синхронизированы(N слов на входе, N - на выходе за некий квант времени), то зачем городить по два буфера на вх и вых? Делайте по одному, с указателями на запись/чтение для вх и вых потока. Логически и задаче и драйверу должно быть проще. Да и в некоторых задачах память поэкономить можно.
Ну и насчёт "одна задача прерывает другую"... В принцЫпе, такое при ОС невозможно, бо прервать выполнение может только ОСь. ИМХО, при ОСи задачи вообше не подозревают о существовании друг друга. Ну разве что письмо одна другой напишет, типа "у меня есть для тебя, возьми под ковриком в прихожей". Мож имеете в виду, что А ждёт данных от Б, а в назначенное время недождалась, и её этим "прервали"?
ИМХО-2, РТмовость можно рассматривать в разных аспектах. Для ваших примеров:
1)должон быть обеспечен жосткий поток данных на вход-выход у МП3 декодера, чего-то ещё(забыл) и 3Д. Например, 44кб/с. Хоть усерись.
2) обработка кнопочек-движОчков-ручек 10-50мС.
3) выдача воздействий от К-Д-Р, примерно, 100-300мС.
Всё это РТ-задачи: звук - понятно, органы управления - тоже. Тоскливо пол-секунды жать на кнопку, чтобы тебя заметили. Ну и воздействие - аналогично, если не уклались, то "резиновая отвёртка" в полный рост. С другой стороны, обрабатывать клавишы раз в 1мС нет смысла. И эквалайзер пересчитывать - тоже. Отсюда неизбежно возникает неизбежность ;О) наличия приоритетов в распределении машынного времени, как разумный компромисс между производительностью машыны и требованием задач. Конешно, когда у нас какой-нить монстр околачивет, это одно. А когда наоборот, это другое. Для монстра околачивающего переключение задач, может, и ничего. А для не-монстра пыхтящего - очень даже плохо. Либо планировщик должен быть продвинутый, а это первый шаг к приоритетам.
|
|
E-mail: 
info@telesys.ru
