arkhnchul писал(а):Строго говоря, ни одна вещь в оной винде не делается без многопоточности.
я вел речь не о строгом функционировании программы в винде, а о том, как видит свою программу программист. например, когда надо читать файл, то его в 90% случаев можно читать "тупо", т.е. открыл и давай в буфер качать до конца. и ничего не произойдет такого, что могло бы встревожить... пока не заняться файлами в гигабайты
а тут окажется, что такой файл читается, мягко говоря, долго, и интерфейс оконный в этот момент тормозит. и приходится думать о вынесении чтения файла в отдельный поток. вот что я имел ввиду, когда говорил, что говорил.
arkhnchul писал(а):Представьте себе другой вариант: вы уже хорошо знакомы с той же OSA и вам вдруг
зачем мне это представлять? последние сообщения в этом топике крутятся вокруг неуёмного желания ЛЮБУЮ задачу подогнать под многопоточное исполнение, при этом знакомства с ОС у автора нет. т.е. многопоточность принимается за некую априори правильную сущность, и уходить от нее нельзя. когда нужда заставляет делить задачу на потоки - это нормально, когда потоки выуждают программиста дробить задачу - это уже странновато. и моё сообщение именно об этом. все-таки не инструмент должен определять решение задачи, а под решение задачи разумно выбрать подходящий инструмент. во всяком случае, мне так кажется.
arkhnchul писал(а):если первая часть высказывания верна, то вторая - не верна)
удивительно, но вы абсолютно правы, и при этом я тоже абсолютно прав
как вы назовете вот такую программу, многопоточной или однопоточной:
Код: Выделить всё
int main(void){
init_all();
while(1){
workjob_1();
workjob_2();
workjob_3();
synchronize();
}
}
?
каждая workjob-функция по сути задача, synchronize обеспечивает ТУПУЮ задержку главного цикла, если от момента предыдущего вызова этой функции прошло менее 10 мс, т.е. эта функция подгоняет длительность итерации главного цикла до 10 мс.
формально - программа абсолютно линейна и ничего параллельного в ней нет. по сути - главный цикл это примитивный шедулер реального времени. но смысл в том, что никаких дополнительных усилий написание такой программы не требует - все делается в рамках парадигмы традиционного однозадачного программирования.
честно говоря, я слегка лукавлю, говоря что все очень просто
например, обработка энкодра при таком подходе вышла у меня немного кривоватой - не хватило терпения доводить до разумно-красивого варианта. получилось несколько вложенных автоматов состояний, в общем, намудрил. и это неизбежное зло именно той самой асинхронности, которая вот так незримо присутствует в моей программе. т.е. решал бы я её средствами ОС, было бы то же самое, тот же гемор. возможно, просто более красиво вышло бы...
я все время хочу как-то осмысленно применять ОС, и подгоняю постепенно решения своих задач под эту парадигму. но почему-то всегда получается, что мои старания убеждают меня в обратном - не применять ОС
