Размышлизма о вреде вытесняющей многозадачности., Все не так просто, как кажется. Опции

[Evgeny_CD]

Есть некий типовой контроллер. 512к FLASH,32к RAM. Такое распределение памяти вызвано объективными технологическими особенностями. И, вероятно так будет долго. Скоро станет 4M FLASH и 256 К SRAM, суть не изменится.

Есть вариант unix идеологии. Когда в памяти живет куча процессов и потоков, различных дискрипторов и структур, и все это в RAM занимает просто мегабайты места. Для однокристальных систем эта идеология слабо подходит.

Пусть есть несколько потков данных. Для каждого из который выделяются некие буфера.

Пусть есть совокупность закоченных процедур, достаточно сложных. Такие процедуры принимают на вход указатель на структуру, что-то там делают (длительное время), активно юзают стек и кучу, но после завершения обработку выдают указатель на выходную структуру, стек на том же самом уровне, и кучу в том же самом состоянии, в каком они ее получили.

Если идти по пути обычных вытесняющих ОСей, и при отсутствии глабального планирования времени, в зависимости от наступления неких критических событий в буферах (близок к переполнению/опустошению) и в окружающем мире (пришло событие, и нам надо срочно его обрабатывать) мы вынуждены будем переключить задачи. Что даст нам неприятность в виде нескольких кадров под стек задач, и бардак в куче, ибо новая задача может затребовать память, ей выделят ее, потом отработает вытесненная ранее задача, она освободит память, но куча уже будет фрагментирована. Дефрагментация кучи - тоска для малоресурсных систем. Для больших, заметим, это тоже фундаментальная проблема.

Если же предположить, что есть некий планировщик, который зная внутреннюю картину системы (сколько чего в буферах, сколько событий ждет обработки), а таже при условии предсказуемости внешнего мира (пример - синхронная система связи, с выделенными кадрами), может более эффективно распределять время.

Типа выбираем блок для обработки, запускаем его с пачкой данных, все остальное копится в буферах. Блок отработал - запустили следующий.

Более того, при запуске такой своебразной задачи, ей можно выделить максимальный квант времени. Она сама смотрит, сколько у нее времени осталось, и если обработка не завершена, она ставит флаг (который ей потом сохранится, он static), чистит стек за собой, и отдает управление системе. Разумеется, алгоритм должен допускать такую возможность дробной обработки.

Также задача может заказать, через сколько ее надо вызвать.

Тогда у планировщика работы системы будет дотаточно данных, чтобы найти оптимальное распределение ресурсов.

Такой подход к работе софтины потребудет специальных тулзов для логического проектирования, ибо прописывать такое все в лоб ручками - это нереально. А вот если использовать некую систему разметки кода, о которых я тут так давно размышляю, это было бы не так уж и сложно.

Комбинация вытесняющего и невытесняющего механизмов была бы, IMHO, очень эффективной.

Вопросы:

* видел ли кто какие наработки по теме?
* какие есть ОСьки, гибко использующие вытесняющий и коопреативный механизмы многозадачности?
* критика и дополнение моих идей.

[vshemm]

А что подразумевается под вытесняющей многозадачностью? Если вытеснение одной задачи другой, - тогда понятие "приоритет" теряет смысл, ибо более приоритетная задача должна вытеснять менее приоритетную; так проще применять матаппараты, которые аналитически позволяют строить подобные системы, например, небезызвестный ЧМА (http://mike.qnx.org.ru/files/articles/rms/rms.doc).

"Ресурсный" вопрос тоже должен решаться на этапе проектирования (мы же не рассматриваем высоконагруженные сервера или базы данных, верно? хотя тут просто используются другие методы). В идеале, динамической памяти вообще быть не должно, или, на худой конец, должны быть раздельные пулы для задач, причем размер пулов должен позволять обрабатывать данные при заданной их интенсивности и производительности вычислителя. В противном случае система просто захлебнется, и никакие стейт машины не спасут.

Так или иначе, возлагать на ОС (планировщик) архитектурные задачи - плохая идея, имхо. Это должен делать человек, в рамках модели ОС, разумеется.

Сети Петри - хорошая штука Жаль, только, задача достижимости в общем случае нерешаема. Плюс разные эффекты, связанные с асинхронностью и недерминированностью.

[zltigo]

А что подразумевается под вытесняющей многозадачностью? Если вытеснение одной задачи другой, - тогда понятие "приоритет" теряет смысл, ибо более приоритетная задача должна вытеснять менее приоритетную

А задачи одного приоритета (или разного, но имеющие на данный момент времени одинаковый приоритет) должны выполняться "параллельно".

"Ресурсный" вопрос тоже должен решаться на этапе проектирования (мы же не рассматриваем высоконагруженные сервера или базы данных, верно?

Не верно. Мы рассматриваем, например, банальный контроллер, который обслуживает несколько каналов связи имеющих разную и пиковую загруженность во времени и соответственно делящий какие-то (даже не свои собственные!) недостающие ресурсы.

В идеале, динамической памяти вообще быть не должно..

Угу, а чего думать - берешь кувалду побольше и ставишь вместо контролера "невысоко нагруженный сервер" ...