OberonCore

Библиотека  Wiki  Форум  BlackBox  Компоненты  Проекты
Текущее время: Четверг, 28 Март, 2024 18:08

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




Начать новую тему Ответить на тему  [ Сообщений: 34 ]  На страницу Пред.  1, 2
Автор Сообщение
 Заголовок сообщения: Re: Единое адресное пространство
СообщениеДобавлено: Воскресенье, 04 Сентябрь, 2016 12:58 
Аватара пользователя

Зарегистрирован: Воскресенье, 12 Апрель, 2015 18:12
Сообщения: 1134
Откуда: СССР v2.0 rc 1
Почитал невнимательно. Плохо нечаянно подумал.

По сути, в такой ситуации требуется каркас, который на голом железе зовётся ОС. Знаем, что в едином адресном пространстве есть несколько легковесных потоков. Роман уже описал подобие дескрипторов для участков памяти в едином адресном пространстве. Потоки могут повредить друг другу. Но исключительно при условии, что код этих потоков начнёт лезть не на свою кафедру. На мой взгляд, тут только два пути залезть:
* попытаться создать ситуацию руками с висячей ссылкой и наугад ломануться.
* Использовать ассемблерные вставки в код.

В обоих случаях, обращение по ссылкам за пределы своего куска адресного пространства должен исполнять каркас. И контроль, куда ведёт эта ссылка. Ассемблерный код запретить де факто. Для этого, код программы распространять в AST. В-принципе, браузеры к этому подошли. Каркас получил код, прошерстил на наличие вставок ASM, выдал предупреждение пользователю и спросил разрешение на запуск. Каркас автоматом: ответ пользователя, скомпиленный и подписанный код сохранил. Если запуск кода вызвал сбой системы -- предварительно поставленная метка запуска модуля подскажет, что что-то не так.

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

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

Адд. https://ru.wikipedia.org/wiki/Microsoft_Singularity -- ребята из Майкрософт Резерш пошли почти по такому же пути. Возможно, ужаснулись эффективности и прикрыли проект, чтобы самим себе не создавать конкуренцию в невыгодном свете существующим продуктам)))


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Единое адресное пространство
СообщениеДобавлено: Понедельник, 05 Сентябрь, 2016 19:08 

Зарегистрирован: Пятница, 26 Август, 2011 23:42
Сообщения: 339
Откуда: Россия, Самара
Есть ли выигрыш от единого адресного пространства? Пример миникс.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Единое адресное пространство
СообщениеДобавлено: Понедельник, 05 Сентябрь, 2016 19:17 
Аватара пользователя

Зарегистрирован: Воскресенье, 12 Апрель, 2015 18:12
Сообщения: 1134
Откуда: СССР v2.0 rc 1
Могу сказать по личному опыту (* не знаю на сколько он адекватен *) при 1000 переключений контекста в секунду при 500 процессах, на все переключения на частоте 600 МГц тратилось до 5% времени ЦП. При 4к переключениях в сек эти затраты резко растут. По моим замерам уже около 30%. Сохранение контекста приводит к диким тормозами -- память накладывает ограничения по скорости. Данные гоняются через кэш, и даже сейчас на мощных ЦП это всё должно вылазить.
В случае плоской памяти позаботиться надо будет о десятке регистров. Теоретически, в системе с большим числом потоков это должно дать существенный выйгрышь. Пример NGINX, Erlang, golang косвенно это подтверждает.

На 500 процессов потребуется 500х10х32=150 кБ памяти контекста + 30 килотактов против 2 МБ + 70 килотактов. И тут с печалью вспоминает, что кэш как Москва -- не резиновый.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Единое адресное пространство
СообщениеДобавлено: Понедельник, 05 Сентябрь, 2016 19:21 

Зарегистрирован: Пятница, 26 Август, 2011 23:42
Сообщения: 339
Откуда: Россия, Самара
prospero78 писал(а):
В случае плоской памяти позаботиться надо будет о десятке регистров. Теоретически, в системе с большим числом потоков это должно дать существенный выйгрышь. Пример NGINX, Erlang, golang косвенно это подтверждает.


Так ведь это программы и языки которые, работают на системе с раздельным адресным пространством? В чём их секрет?


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Единое адресное пространство
СообщениеДобавлено: Понедельник, 05 Сентябрь, 2016 19:25 

Зарегистрирован: Пятница, 26 Август, 2011 23:42
Сообщения: 339
Откуда: Россия, Самара
Выражусь, точнее, есть же техники, реализации, паттерны которые уменьшают затраты, на переключение контекста?


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Единое адресное пространство
СообщениеДобавлено: Понедельник, 05 Сентябрь, 2016 19:28 

Зарегистрирован: Пятница, 26 Август, 2011 23:42
Сообщения: 339
Откуда: Россия, Самара
Насчёт злого умысла, допустим программа прошла все проверки, но ведь можно любым хекс редактором подправить уже скомпилированную программу вручную.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Единое адресное пространство
СообщениеДобавлено: Понедельник, 05 Сентябрь, 2016 19:51 
Аватара пользователя

Зарегистрирован: Воскресенье, 12 Апрель, 2015 18:12
Сообщения: 1134
Откуда: СССР v2.0 rc 1
Программа в форме AST. И прежде чем она будет запущена -- она будет проверена, скомпилена, и бинарник подписан. А чтобы залезть в память -- надо разрешение. Теоретически, можно принести зловред в виде бинарника с собой. Как запустить? Система не позволит))


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Единое адресное пространство
СообщениеДобавлено: Понедельник, 05 Сентябрь, 2016 22:20 

Зарегистрирован: Понедельник, 30 Июль, 2007 10:53
Сообщения: 1538
Откуда: Беларусь, Минск
Jordan писал(а):
Выражусь, точнее, есть же техники, реализации, паттерны которые уменьшают затраты, на переключение контекста?
А ссылку?
В системах с вытесняющей многозадачностью переключение контекста аппаратное. Обработчик прерывания не различает процессы. Сами процессы тоже не в курсе моментов переключения. Переключение затрагивает регистры, кэш и таблицу виртуальной памяти. Куда тут технику или паттерн воткнуть?


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Единое адресное пространство
СообщениеДобавлено: Понедельник, 05 Сентябрь, 2016 22:36 

Зарегистрирован: Понедельник, 30 Июль, 2007 10:53
Сообщения: 1538
Откуда: Беларусь, Минск
Jordan писал(а):
Насчёт злого умысла, допустим программа прошла все проверки, но ведь можно любым хекс редактором подправить уже скомпилированную программу вручную.
Механизмы защиты от этого известны давно. Живым примером может служить яФон.
Какую-либо программу, предназначенную для редактирования имеет смысл применять только для того, что предназначалось для редактирования. Исполнимые файлы предназначены для исполнения. Как их защитить от изменения? Хранить код не в виде файлов (которые всегда были абстракцией данных), а другим способом и в таком месте, которое находится за пределами пользовательской оболочки операционной системы. То есть, в скрытом от пользователей хранилище. Запуск приложения и разнообразную информацию о нём нужно получать с помощью специальных команд операционной системы.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Единое адресное пространство
СообщениеДобавлено: Вторник, 06 Сентябрь, 2016 09:36 
Аватара пользователя

Зарегистрирован: Воскресенье, 12 Апрель, 2015 18:12
Сообщения: 1134
Откуда: СССР v2.0 rc 1
Valery Solovey писал(а):
...В системах с вытесняющей многозадачностью переключение контекста аппаратное. Обработчик прерывания не различает процессы. Сами процессы тоже не в курсе моментов переключения. Переключение затрагивает регистры, кэш и таблицу виртуальной памяти. Куда тут технику или паттерн воткнуть?

Контекстные переключения, действительно, аппаратные. И в этом смысле ничего упростить нельзя, соглашусь с замечанием. При этом, в продолжение темы эффективности плоской памяти добавлю, что при плоской памяти всё так же работают аппаратные и программные прерывания. И нет проблем дописать в ядро в таблице процессов в виде массива RECORD с признаками информации о том, какому процессу сколько квантов выделить и какой приоритет процессу задать Всё доступно Jordan, берите и пользуйте.
Вот только аппаратные прерывания настраиваются через машинный код и ассемблер, который запрещён в языке (или той части, которая запускается ядром как простой процесс, или без особого разрешения пользователя).
Поэтому обращение к памяти допустимо, но вот только скажем так:
Код:
Mem.PeekInt(adr, len); (* но через ядро *)
Mem.PokeByte(adr, array_byte); (* но опять же через ядро!!! *)
Kernel.Process_start(process_id);  (* и нет другого способа выполнить код, а передать выполнение в произвольную точку -- такие права только у ядра *)

Прямой доступ исключен. Кэш всё ещё нужен, и организация его проще. Таблица виртуальной памяти просто не нужна. Паттерн, техника?))) Да всё что угодно.
Кроме того, кто мешает в ходе компиляции подсчитывать необходимое количество тактов для исполнения программы. И после заданного количеств тактов, из расчёта наихудшей ситуации, компилятор пусть втыкает системный вызов:
Код:
Kernel.Quant_end;

В таком случае, даже аппаратное прерывание не нужно!))


Valery Solovey писал(а):
Механизмы защиты от этого известны давно. Живым примером может служить яФон.

Парень явно в теме)))

Valery Solovey писал(а):
Исполнимые файлы предназначены для исполнения. Как их защитить от изменения? Хранить код не в виде файлов (которые всегда были абстракцией данных), а другим способом и в таком месте, которое находится за пределами пользовательской оболочки операционной системы. То есть, в скрытом от пользователей хранилище. Запуск приложения и разнообразную информацию о нём нужно получать с помощью специальных команд операционной системы.

Совершенно верно. Можно даже бинарники хранить. Но в сухом и недоступном для детей месте. Эта идея просто напрашивается. И только религия не позволяет это сделать в существующих ОС.

В конце концов, можно даже запускать неизвестные бинарники. Правда в виртуальной-софт машине. Будет быстродействие смешное, но в качестве песочницы пусть отработает, скажем 1 млн. квантов времени. При обращении к системным вызовам -- исполнять аппаратно, вне виртуальной машины. Это прилично ускорит неизвестный бинарный код, и всё ещё будет безопасно.

Так что, идея плоского пространства реализуема, если будет под такую модель язык. Вирт занимается именно этим))


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Единое адресное пространство
СообщениеДобавлено: Вторник, 06 Сентябрь, 2016 17:54 

Зарегистрирован: Пятница, 26 Август, 2011 23:42
Сообщения: 339
Откуда: Россия, Самара
Спасибо за ответы, картинка начинает прорисовываться. Я собсно, вообще пофлеймить зашёл, а Вы отвечаете, разъясняете. :)


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Единое адресное пространство
СообщениеДобавлено: Вторник, 06 Сентябрь, 2016 21:35 

Зарегистрирован: Понедельник, 30 Июль, 2007 10:53
Сообщения: 1538
Откуда: Беларусь, Минск
prospero78 писал(а):
Таблица виртуальной памяти просто не нужна.
Виртуальная память всё ещё нужна. Её используют не только для разделения адресных пространств процессов, но ещё и для расширения оперативной памяти за счёт диска.
prospero78 писал(а):
Можно даже бинарники хранить. Но в сухом и недоступном для детей месте. Эта идея просто напрашивается. И только религия не позволяет это сделать в существующих ОС.
Я сейчас не хочу просматривать родословную винды и доса, но как минимум линукс вырос из юникса. А в юниксе была идея, что "всё есть файл". План9 продолжает эту традицию, и в нём даже процессы и запросы к серверам являются файлами. И в этом есть смысл. Такой подход позволяет достичь большой гибкости: если есть инструмент, который работает с файлами, то он сможет работать с процессами или отправлять запросы на сервер. Но большинство наследников юникса отошли от его главной идеи, и теперь многое из того, что было ими перенято, сейчас просто рудимент.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Единое адресное пространство
СообщениеДобавлено: Вторник, 06 Сентябрь, 2016 22:02 
Аватара пользователя

Зарегистрирован: Воскресенье, 12 Апрель, 2015 18:12
Сообщения: 1134
Откуда: СССР v2.0 rc 1
Valery Solovey писал(а):
Виртуальная память всё ещё нужна. Её используют не только для разделения адресных пространств процессов, но ещё и для расширения оперативной памяти за счёт диска.

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

Valery Solovey писал(а):
Но большинство наследников юникса отошли от его главной идеи, и теперь многое из того, что было ими перенято, сейчас просто рудимент.

Ну, хоть идея была перспективна, отошли от неё именно потому, что работать с регистром процессора всё-таки не выйдет как с файлом. Темп его "жизни" на порядки выше, вычислительной мощности человека. Но попытка стандартизации вызовов, безусловно достойна. Идея всего как файла, думаю, ещё будет очень долго жить. Даже модные ныне JSON-запросы поверх HTTP, можно архаично отобразить на каталог с необходимым количеством файлов для чтения)). Но это дорогой механизм. Если какой-то процесс позволяет вызывать его процедуры-сервисы по ссылке -- так на кой ляд привлекать файлы? Это очень жирный кусок масла сверху. Хотя, повторюсь -- да. мажется с удовольствием.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Единое адресное пространство
СообщениеДобавлено: Суббота, 03 Март, 2018 23:36 

Зарегистрирован: Среда, 31 Январь, 2018 19:54
Сообщения: 244
Alexey Veselovsky писал(а):
Без мапинга невозможно эффективно работать с устройствами. Например с видеокамерами. PS. Да, linux.

В KolibriOS можно из прикладной программы обращаться ко всей физической памяти.


Вернуться к началу
 Профиль  
 
Показать сообщения за:  Поле сортировки  
Начать новую тему Ответить на тему  [ Сообщений: 34 ]  На страницу Пред.  1, 2

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


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

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


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

Найти:
Вся информация, размещаемая участниками на конференции (тексты сообщений, вложения и пр.) © 2005-2024, участники конференции «OberonCore», если специально не оговорено иное.
Администрация не несет ответственности за мнения, стиль и достоверность высказываний участников, равно как и за безопасность материалов, предоставляемых участниками во вложениях.
Без разрешения участников и ссылки на конференцию «OberonCore» любое воспроизведение и/или копирование высказываний полностью и/или по частям запрещено.
Powered by phpBB® Forum Software © phpBB Group
Русская поддержка phpBB