В данном случае создается только видимость многопотоковость - в системе в любой момент времени исполняется только один поток и только, без прерывания исполнения - поток должен сам отдать управление. Планировщик достаточно прост: кто первый заблокировался первым и разблокируется - в общем удобно и предсказуемо. Для программирования основным неудобством остается хранение всех переменных в специальной структуре описателе контекста, все остальные моменты вполне хорошо скрываются от программиста. Используется переход при вызове функции сразу на адрес остановки - создается видимость одновременного непрерывного исполнения кода - код в принципе должен быть простым. При переносимости могут возникнуть проблемы только с метками - но их можно решить создавая, например: скрытый свич - где каждая точка будет отмечаться какой то меткой. Так обычно пишут программы демонстрирующие работы многопоточных алгоритмов - при определенной доле фантазии можно, что то придумать - единственная проблема возможно будет ограничено количество блокировок в функции - можно ожидать только одного сигнала, то есть функцию нужно разбивать на 3 ветви:
- обычное исполнение(старт с начала),
- блокировка,
- код после блокировки.
В данном алгоритме блокировки осуществляются достаточно хорошо - сложно обратиться к ресурсу несколько раз, если поток всегда один без прерываний. Основная проблема возможен случай тупика при не корректном занимании ресурсов, каждый поток захватит только часть, а для окончания работы нужно полный объем, но до таких сложностей еще долго, как мне кажется. Но если начать разбивать потоки по ядрам - возможны проблемы, так как нужно более надежно блокировать ресурсы к которым может быть обращение в нескольких потоках на разных ядрах, появиться требование описывать в контексте какие ресурсы могут понадобиться. Такая идея была частично в Singularity, но только для описания потоков с блокировкой получения не указанных в описании ресурсов. В общем случае, эта реализация ничем не хуже по описанию чем остальные - даже лучше, так как позволяет без использования языков оптимизированных под реализацию событично-ориентированной модели получить ее достоинства в С. Если добавить еще возможность использования хоть самого простой реализации сборщика мусора - очень хороший алгоритм для реализации надежных систем (не обязательно в контексте использования) с обязательным детерменизмом исполнения. С памятью особых проблем быть не должно так как в контексте исполнения указывается ее максимальный объем и можно посчитать реальное использование - для случая когда этот момент очень важен.
No comments:
Post a Comment