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

[Evgeny_CD]

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

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

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

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

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

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

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

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

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

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

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

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

Вопросы:

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

[Evgeny_CD]

caxapa:: Рэйлвэй Каген {

При всём богатстве выбора, альтернатив, как всегда, две
А именно - есть алгебраисты и алгоритмисты.

Первым ближе сети, графы и автоматы. К перечисленным средствам могу добавить только
CPN Tools http://www.daimi.au.dk/~cpntools . Впрочем, это уже было здесь: http://caxapa.ru/110159.html
Для генерации в плюсАх можно посмотреть gsmsuite http://www.boutell.com/lsm/lsmbyid.cgi/000341

Вторым - Дракон http://wiki.oberoncore.ru/index.php/%D0%94...%B7%D0%BE%D1%80
Дракон-редактор http://narod.ru/disk/55428000/DRT.rar
По сути - очередная реинкарнация блок-схем с полуавтоматической генерацией кода.
Паронджанов В.Д. Как улучшить работу ума. Алгоритмы без программистов — это очень
просто!(Новые средства для образного представления знаний, развития интелекта и
взаимопонимания). М.: Дело, 2001. — 360 с. — Илл.: 154.
http://www.transhumanism-russia.ru/documen...tu_uma_Word.rar
Недавняя дискуссия здесь http://forum.oberoncore.ru/viewtopic.php?f=62&t=493 ,
в том числе и по общим подходам к визуализации программ.

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

Мне добавить нечего

Кое-что добавлю.

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

Но меня удивляет то, что нет толковых общепринятых тулзов для этого. С/С++ компилеров и их вариантов вон сколько наплодили, а такого генератора/верфикатора нет. Или это жутко конкурентная область, и все заныкали свои наработки под матрасами??? -

Сообщение отредактировал Evgeny_CD - Jun 14 2008, 13:59

[zltigo]

Или это жутко конкурентная область, и все заныкали свои наработки под матрасами??? -

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

[Evgeny_CD]

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

Есть такое. Меня удивляет, что никто не сделал "полуавтоматический" инструмент. (Полностью автоматический инструмент - утопия, тут и спорить не о чем).

Есть изначальный граф - описание алгоритма. Генерируем код.

Код разбиваем на блоки (хоть чезер маркеры в каментах, хоть еще как).

В кажом блоке описываются его характеристики:

* export - чем из этого блока можно пользоваться снаружи
* import - чем он сам пользуется
* config - заивсимость от параметров конфигурации
* OS - какие средства ОСи блок использует.

Все связи между блоками прописываются на уровне графа и только так!

Далее на уровне блока проверятся - блок соотвествует своему дескриптору или нет?

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

Далее берем блок кода и начинаем глазками/ручками/мозгами доводит его до совершенства.

Полной автоматической кодогерации делать смысла никакого нет.

При герерации заготовки блока генерируются заготовки его export сущностей и import данных, с которыми он работет. Ну и словами - что этот блок сделать должен.

Блоки могут быть вложенными.

Далее верификауция идет в два этапа.

На уровне формальной верификации проверяем, что блок соотвествует дескриптору.

На уровне функуциональном прогоняем тест и убеждаемся, что блок делает то, что нам надо, а не ему.

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

Вот и вся автоматизация. Никакого "искусственного интеллекта" и пр. шняг не предвидится. Все просто и тупо, в моем понимании на год неспешной работы пары толковых программистов.

Вопрос в том, почему так никто не сделал???