Если вы про мой планировщик, то это скорее способ организации
исходного текста (потому и sheduler), нежели претензия на
кооперативную ОС. Но при этом часть указанных вами проблем учтены. Криво, косо, но учтены. Приоритет - нужная задача ближе к началу обхода. Задача не вызывается, если для неё нет события. Если задача сработала, обходим список заново, вдруг она для приоритетной насчитала что-нить или долго думала.(сомнительный момент - если хотя бы 50 элементов перебрать, уже чувствительно) (На списках получается гибче конструкция, но сложнее обход списка и требует выделения/освобождения памяти.) Да, проверить и перейти на следующий элемент - время, но предполагаю, что сильно меньшее запуска. Задача сама не может себя поставить в очередь(цикл ожидания в лоб не организовать или сразу в тексте функцци-задачи, но тогда всё сломается); это по идеямпостаКсении в том числе. Много событий для задачи запускает её один раз. Цикл планировщика намерено разорван, чтобы можно было и уснуть, и проверить что-нить. Опять же, если задачи не прерываются извне(irq, OS), то примитивы синхронизации могут быть сделаны на обычных переменных, так как доступ из задач "атомарный". Их реализация действительно важна, когда 10К problem реальна, а у этого планировщика её не должно быть(не тот масштаб применения). Посмотрите, вот здесь старая штука от TI, может любопытно будет. Сегодня наткнулся. Как раз очередь с приоритетами используется. Большего пока не понял, позже ещё поковыряюсь.
Dingo (06.12.2020 21:29, просмотров: 558) ответил fk0 на Очевидно, что без механизма ожидания -- получается полная ерунда, которая ничем не лучше биглупа. Когда
событий станет много (типов событий, происходить им не обязательно)
-- всё время только и будет уходить на такие циклы проверки, как и
в биглупе. Зачем тогда сущность с громким названием "операционка"?