1. Переключение между потоками это затраты.
переключений между потоками нет. Поток "спит" на WaitFor..Objects ожмдая своих WaitableTimer, Event и прочее.
у меня, например, суммарная нагрузка от потоков, например двух GPS, не превышает тысячной процента! Поток получает управление один раз в секунду при приеме терминального символа и все. А поток отслеживания состояния светофор и стрелок и того реже - только когда эти переключения происходят. Откуда переключения?
2. Мютексы это затраты
никаких мьютексов. критические секции. она не является объектом ядра. затраты = 0.
для устранения взаимных блокировок одно строгое правило: внутри критической секции никаких других критических секций!
3. Усложнение архитектуры
внешний исходный код упрощается очень сильно. например работа с принтером в основном потоке:
POS_Printer printer("COM3");
(да - динамических объектов стараемся избегать для исключения сюрпризов с веделением памяти, все что нужно выделается сразу чтобы сразу знать что "непойдет", а не потом, когда уже поздно).
if(POS_Printer.Start() != true)
{
// все плохо! думаем что дальше.
}
где надо печатать:
if(printer.Get_State(&state) != true)
{
// все плохо! думаем что дальше.
}
else
{
if(state.OffLine())....
if(state.PaperEnd()).....
настраиваем принтер..
// с принтером все хорошо.
// кидаем в принтер кучу заданий.
// по первому заданию он сразу в фоне начинает печатать.
for(;
printer.AddTask();
}
все "прозрачно" - все использование в одном экране! Никаких "прыганий" по исходнику.
4. Большая вероятность допуска ошибки, которую крайне тяжело будет вычленить.
ну это на совести программиста. Ошибку можно и на ровном месте допустить.
а при наличии уже отработанного класса его использование резко упрощается, вероятность ошибки минимальна (см. приведенный выше псевдо код - в чем там можно ошибиться?)
По поводу загрузки на 100% - загружает не канал, а обработка данных - обработка должна уметь правильно рулить ресурсами и не допускать такого поведения.
какая разница что загружает? мне при приеме пакета надо парсить = искать флаги, считать контрольную сумму, если не совпала - искать новый флаг, считать новую сумму. и так по всему буферу приема по каждому принятому байта. А загружало даже не это: периодически происходили ошибки порта, типа прием BREAK, ошибка parity и прочее. По каждой ошибке пытались что-то сделать, переинициализировать порт и прочее.......
