OSDev

для всех
Текущее время: 28 мар 2024, 11:33

Часовой пояс: UTC + 3 часа




Начать новую тему Ответить на тему  [ Сообщений: 9 ] 
Автор Сообщение
СообщениеДобавлено: 13 май 2019, 20:12 

Зарегистрирован: 05 ноя 2018, 14:34
Сообщения: 6
Добрый день!
Пилю свою недоось для cortex M, правда написал пока один аллокатор.
Код всех программ будет располагаться во флеш, ОЗУ только для данных и стеков задач
Какой подход был бы самым грамотным учитывая все вышеприведенное при реализации многозадачной ОС?

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

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

на какие грабли здесь можно наступить? как сделать правильно? спасибо


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: 13 май 2019, 21:16 

Зарегистрирован: 28 окт 2007, 18:33
Сообщения: 1418
Если задачи никак не изолированы друг от друга, то разумней говорить не о задачах, а о потоках одной общей неявной задачи. Тогда да: вся память общая (даже стеки взаимно доступны -- просто указатель стека у каждого потока свой). Если же делать полноценную многозадачность, а не многопоточность, т.е. с возможностью изоляции задач друг от друга (большинство ядер Cortex-M дают такую возможность при использовании MPU, хотя в некоторых реализациях сие устройство может отсутствовать), тогда придётся память выделять заранее, а само число задач ограничено возможностями MPU.

ADD. В OS/360 (скоммунизженной нами под вывеской ОС ЕС) изначально был только т.н. режим с фиксированным числом задач (MFT), когда вся основная память (в IBMовской терминологии) делилась на разделы определённого размера и уже в этих разделах выполнялись задачи; понятно, что число задач не могло превосходить количества разделов, а оно было фиксированным (управляющие блоки строились при генерации -- т.е. сборке -- системы; оператор впоследствии мог менять их размеры, но не мог изменить число). Поздней появился режим с переменным числом задач (MVT), где разделы создавались и уничтожались системой динамически при запуске/прекращении задач, но при этом каждый раздел должен был быть непрерывным (виртуальной памяти не было, поскольку сама Система 360 не имела аппаратной поддержки, она появилась лишь в Системе 370). В качестве необязательного механизма (выбираемого при генерации) в MVT была так называемая свёртка-развёртка. Суть в том, что, если некая задача хотела расшириться, а раздел уже был исчерпан, то, если эта задача обладала необходимыми привилегиями, ОС переписывала на диск содержимое другого раздела, смежного с первым, после чего расширяла первый раздел. Когда раздел опять сокращался или уничтожался, второй раздел вновь создавался, с диска производилась загрузка его содержимого, и задача во втором разделе могла продолжать работу. До появления виртуальной памяти это, по сути, единственный способ обеспечить задаче выделения дополнительной памяти, не предусмотренной заранее, если нельзя выделять память с разрывами. Конкретно в ОС/360 можно было бы реализовать и разрывное выделение, т.к. механизм защиты памяти Системы 360 такое позволял, но в АРМах с MPU это не прокатит.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: 13 май 2019, 21:50 
Аватара пользователя

Зарегистрирован: 16 май 2007, 23:46
Сообщения: 1126
Цитата:
ак выделять память для задач, видел что существует такой подход- каждой задаче выделяют некоторый объем, в этом объеме насколько понимаю и данные и стек, все вместе. Что произойдет если задаче в процессе ее выполнения потребуется больший объем памяти, объем которого трудно спрогнозировать заранее, например под буфер, закладывать большой объем сразу не разумно, да и не угадаешь с его размером, что тогда делать выделять еще один большой объем памяти для этой задачи? как-то не нравится мне такое решение

Это называется не контролируемый рост памяти. Такого быть не должно. Исходя из этого утверждения вам за ботится о этом не нужно. Это забота прикладного программиста, а ни системного.
Размер буфера либо фиксирован либо оговорен максимум. Есть 3-х этапное рукопожатие на котором согласуется размер буфера.
Если буфер заполнен то он релоцируется, т.е. выделяется объем в 1٫5 раза больше и данные со старого адреса переносятся на новый. Старый буфер освобождается.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: 13 май 2019, 22:16 

Зарегистрирован: 05 ноя 2018, 14:34
Сообщения: 6
признаюсь не вникал глубоко в работу MPU на cortex, но помню что там всего на 8 регионов можно разбить, 1 регион для ОС, остается всего 7, маловато будет.

SII писал(а):
До появления виртуальной памяти это, по сути, единственный способ обеспечить задаче выделения дополнительной памяти, не предусмотренной заранее, если нельзя выделять память с разрывами. Конкретно в ОС/360 можно было бы реализовать и разрывное выделение, т.к. механизм защиты памяти Системы 360 такое позволял, но в АРМах с MPU это не прокатит.


почему же в os/360 не было реализовано динамическое выделение памяти? если возможность реализации была.

pavia писал(а):
Если буфер заполнен то он релоцируется, т.е. выделяется объем в 1٫5 раза больше и данные со старого адреса переносятся на новый. Старый буфер освобождается


идея интересная, вопрос другой, а откуда выделяется эта память под новый буфер, из кучи? мне непонятно сколько книг не пересмотрел, где находится эта куча? из кучи процесса, или это куча общая для всех процессов


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: 13 май 2019, 22:50 

Зарегистрирован: 28 окт 2007, 18:33
Сообщения: 1418
SLD писал(а):
почему же в os/360 не было реализовано динамическое выделение памяти? если возможность реализации была.


Вы валите в кучу сразу несколько вещей. Динамическая память (в смысле куча) там, естественно, была -- причём своя у ядра и своя в каждом из разделов. Но динамическая память к многозадачности вообще никакого отношения не имеет, а к "глобальному" разделению памяти (на разделы между задачами) -- очень косвенное. А для чего сделали статические разделы в MFT... Ну так это элементарно: для упрощения системы, уменьшения требуемой памяти и увеличения скорости работы. Машины-то тогда были слегка помедленнее (и побольше) нынешних.

В моей системе, кстати, эти варианты тоже присутствуют, причём фактически сейчас у меня реализован, и то пока частично, лишь MFT. Но здесь дело в специализации: сейчас я делаю ОС для микроконтроллерных применений, а там прошивка известна заранее, никакой нужды в загрузке задач на лету нет вообще (да и грузить неоткуда -- всё во флэше лежит), ну и зачем мне динамически распределять память между задачами, когда я это благополучно делаю статически во время сборки системы? В этом плане мой MFT (я даже эти обозначения украл) хуже, чем в ОС/360: в этом режиме у меня в принципе нет загрузки задач (вот в MVT уже будет, и тем более в вариантах с вирутальной памятью).


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: 14 май 2019, 13:45 
Аватара пользователя

Зарегистрирован: 14 мар 2011, 12:31
Сообщения: 970
Откуда: Дагоба
SLD,
Тут как раз недавно обсуждалась похожая тема, почитайте в ней ответы на тему кучи и выделения памяти задачам: http://osdev.ru/viewtopic.php?t=3666.

_________________
Yet Other Developer of Architecture.
The mistery of Yoda’s speech uncovered is:
Just an old Forth programmer Yoda was.

<<< OS Boot Tools. >>>


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: 15 май 2019, 21:06 

Зарегистрирован: 05 ноя 2018, 14:34
Сообщения: 6
SII писал(а):
Если же делать полноценную многозадачность, а не многопоточность, т.е. с возможностью изоляции задач друг от друга (большинство ядер Cortex-M дают такую возможность при использовании MPU, хотя в некоторых реализациях сие устройство может отсутствовать), тогда придётся память выделять заранее, а само число задач ограничено возможностями MPU..


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

единственное что пришло на ум это в процессе переключения контекста каждый раз перенастраивать MPU таким образом чтобы блок с данными и стеком работающей задачи был открыт для чтения и записи в него, а вся остальная область ОЗУ содержащая данные и стеки других задач под запретом.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: 15 май 2019, 23:29 

Зарегистрирован: 28 окт 2007, 18:33
Сообщения: 1418
SLD писал(а):
Раз Вам хорошо знакома работа MPU в кортекс


Увы, если б хорошо знал, уже описал бы на нашей Вике -- а так всё руки не доходят разобраться...

Цитата:
позвольте еще вопрос, как реализуется защита пользовательских задач одна от другой с его помощью? как защитить операционную систему от пользовательской задачи я понял, а как пользовательские задачи друг от друга нет. Говоря о пользовательских задачах я имею ввиду данные и стеки этих задач расположенные в ОЗУ.

единственное что пришло на ум это в процессе переключения контекста каждый раз перенастраивать MPU таким образом чтобы блок с данными и стеком работающей задачи был открыт для чтения и записи в него, а вся остальная область ОЗУ содержащая данные и стеки других задач под запретом.


Похоже, что Вы правы и это действительно единственно возможный способ. Он вполне приемлем по скорости: регионов-то немного, так что при переключении задач потребуется всего несколько дополнительных команд.

Замечу, что с помощью MPU можно реализовать и разрывное адресное пространство -- скажем, есть некое общее поле памяти, используемое совместно несколькими задачами, и индивидуальные пространства задач.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: 20 май 2019, 14:26 

Зарегистрирован: 16 апр 2019, 17:15
Сообщения: 11
Добрый день.

Цитата:
что если все данные всех задач размещать в куче, выделяя динамически сколько и кому требуется, а стеки всех задач держать отдельно? глубину стеков то можно плюс-минус примерно рассчитать, с запасом


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

По поводу организации многозадачности, тут нужно исходить из функциональности целевого ПО, а не аппаратной плптформы. Вполне возможно Вам хватит кооперативной (не вытесняемой многозадачности). Ну а если нужна уж прямо полноценная многозадачность, то можно сделать следующий вариант. Задача представляет из себя накопитель ресурсов, в том числе и памяти (стек например), ресурсы еще могут быть например индексные дескрипторы (используемые файлы), объекты синхронизации, таймеры, и так далее. Единую кучу зарезервируйте в статическом месте с помощью линкер скрипта, алгоритм аллокации прилепите сверху). В Embox это получилось самое оптимальное решение для микроконтроллреов если требуется уж полноценная (без fork) многозадачность.


Вернуться к началу
 Профиль  
 
Показать сообщения за:  Поле сортировки  
Начать новую тему Ответить на тему  [ Сообщений: 9 ] 

Часовой пояс: UTC + 3 часа


Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 1


Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения

Найти:
Перейти:  
cron
Создано на основе phpBB® Forum Software © phpBB Group
Русская поддержка phpBB