Rambler's
Top100

Разработка операционных систем. Выпуск 14

Автор: lonesome [TSH/Digital Daemons]
Дата: 18.06.2003
Раздел: Разработка ОС

ПРЕДЫДУЩИЙ ВЫПУСК      СЛЕДУЮЩИЙ ВЫПУСК

Разработка операционных систем

Выпуск 14 от [SUBSCRIBE issue_date]

Сегодня в номере:

Intro

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

И напоследок - загляните в раздел "Идеи" - очень интересная идея по архитектуре ОС от Павла Некрасова

Многозадачность

Вероятно никому не нужно объяснять, что такое многозадачность, но для полноты картины все же приведем "сухое" научное определение:

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

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

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

По какому принципу может осуществляться многозадачность?
1) сама задача может время от времени передавать управление другой задаче
2) управление может поочередно отбираться от задачи и передаваться другой задаче

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

Три параметра многозадачной вычислительной системы

Эффективность работы многозадачной вычислительной системы определяется тремя параметрами:

К сожалению, эти параметры взаимоисключаемы. Это привело к разделению многозадачных систем на три типа, каждый из которых делает упор на один из этих параметров. Наибольшую пропускную способность имеют уже знакомые нам системы пакетной обработки. Вы спросите - какой смысл делать многозадачными системы пакетной обработки?! Ответ прост - определенную часть своего выполнения программа затрачивает на операции ввода/вывода (которые, как правило, не требуют участия центрального процессора, а значит могут выполняться параллельно с программой). Пока одна из программ ожидает завершения операции ввода/вывода, к процессору допускается другая программа. В результате многозадачность приводит к значительному "уплотнению" выполнения программ, а значит и обеспечивает большую пропускную способность, нежели характерное для систем пакетной обработки однозадачное выполнение программ по очереди

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

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

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

Идеи

Напоминаю, что любые идеи касающиеся разработки ОС, вы можете присылать по адресу: lonesome@lowlevel.ru

Идея номер 3 (Автор: Игорь А. Остриков):

> Кстати у меня появилась небольшая идейка по файловой системе: сделать
> к файлу новый аттрибут "удалить физически" или его можно как-нибудь по
> другому назвать. Смысл в нем такой, перед удалением файла выставить
> этот аттрибут и система его удалит так чтобы невозможно было его
> восстановить. 

Идея номер 4 (Автор: WerWolf):

> Вот все например
> пользуются ВинАмпом, мне больше нравиться Соник. Как-то я впервые
> поставил к нему ДЭЭФИКС. Звук становится куда лучше, но к сожалению я
> не могу ведь сделать так, чтобы Соник (точнее ДЭЭФИКС) проигрывал звуки
> из игрушек, когда я играю. А почему бы не засылать покеты данных
> вместо стандартного устройства вывода на тот же Соник, а он уже,
> обработав их, пошлёт на саунд-кард. В принципе я предлагаю все данные
> передавать пакетами. Как реализовать подобную фишку в Винде я не знаю,
> так что предлагаю сделать это стандартным в ОСьке.

Идея номер 5 (Автор: WerWolf):

>    Ну и ещё одна идея касалась виртуальной памяти.
>    Одна из тех вещей которые мне не нравиться в Виндоус - это то что
> при переключении задач (при помоши Alt+Tab) она очень долго думает. Я
> предлагаю при переключении задачи скопировать память на диск и не всю
> сразу а не большой кусочек и пометить где нибуть, что мол я скопал
> память на диск, но пока её не удалял. И если вдруг переключение между
> задачами произошло случайно, то вернуться в прежнюю можно без труда, не
> считывая всё с диска, а лишь опять установив в памяти присутствие
> блоков. Кроме всего, так как процесс записи на диск можно исполнять
> параллельно с выполнением программы, то это явно упростит задачу.
> 

Идея номер 6 (Автор: Павел Некрасов aka Billy Bons):

> 
> Предлагаю следующую идею по поводу архитектуры ОС(хотя в общем-то это
> не моя идея, работа в этом направлении, как я понимаю идет уже давно
> на разных платформах, но было бы чрезвычайно интересно её реализовать
> ). Я предлагаю рассмотреть вопрос о файловой системе, как хранилище
> информации. С точки зрения пользователя, его интересуют прежде всего
> данные, его данные, которые где-то хранятся, в сети (это сейчас не
> рассматриваем) или на локальном компьютере. Я предлагаю организовать
> хранилище пользовательских данных и программ на основе БД. Тут скорее
> всего просто придется отказаться от такого понятия как файл в
> традиционном понимании этого слова. Чего можно этим достичь? Во
> первых, как во всякой БД, можно реализовать через log _файл простое
> отслеживание (протоколирование) всех изменений и возможность отката
> изменений на определенную дату. Этим же частично решается и проблема
> Backup'а. Пользователь работает со своими данными через едино образный
> интерфейс (что мешает сделать что-то типа Explorera или shella ,
> которые на системный вызов open или createfile организуют SQL-запрос к
> движку БД) или транслируют запрос по сети к движку БД на другом
> компьютере. При помощи БД можно реализовать и поддержку транзакций -
> это очень важная вещь. Возьмём, например технологию COM+ на Win32. Так
> для поддержки транзакции компонент должен был реализовать определённый
> интерфейс, методы отката и т.д. Тут же можно всё сделать проще.
> Реализовать, допустим системные вызовы  типа BeginTran CommitTran
> RollBackTran. И все изменения в различных файлах, которые делает
> пользовательский процесс управляются этими вызовами. Рухнул внезапно
> процесс - при выгрузке его из памяти, проверяем, есть ли открытые
> транзакции  и откатываем их, если есть. Для примера, кто знает 1С, там
> если такое произойдет, надо программу запускать в монопольном режиме
> переиндексировать файлы и т.д. А зачастую и просто восстанавливать из
> Backup. Еще одна вещь - безопасность. Проверку доступа к данным берёт
> на себя БД, но тут не все так просто - надо продумать.
> 
> Архитектура ОС c точки зрения файловой системы может быть такова: 1)
> системный раздел - представляет собой традиционную файловую систему
> (хошь FAT, ext2fs и т.д.). Здесь хранятся файлы и программы
> необходимые для функционирования самой ОС - ядро, драйвера необходимые
> для функционирования ОС (но не, допустим, драйвера принтеров) и сам
> движок пользовательского хранилища. При загрузке ОС инициализирует
> себя, загружает нужные драйвера устройств, которые, опять-таки нужны
> ей самой, и в конце загрузки загружает движок пользовательского
> хранилища, который 2) находит раздел пользовательского хранилища -
> саму БД и 3) раздел лог файла. Фактически на разделах 2 и 3 хранится
> только по одному огромному файлу, доступ к содержимому которых
> управляется через движок самой БД. Далее загружаются какие-то
> программы из БД для инизиализации системы окружения пользователя,
> загружаются драйвера принтеров, если необходимы и т.д. запускается
> процесс аутенфикации пользоваиеля.
> 
> Как видно в предлагаемой архитектуре все равно присутсвует файловая
> система в обычном понимании. Только хранятся там программы и данные
> необходимые только для самой ОС. Можно сделать так, что пользователю
> этот раздел вообще не виден и недоступен (так наверное и надо). Если
> надо что-то сделать с самой системой на этом уровне можно (ядро
> обновить) можно предусмотреть загрузку ОС в специальном режиме и т.д.
> Программы и данные не необходимые как таковые ОС хранятся в
> БД(хранилище) и управляются ею.
> 
> Опять же идея эта находит уже свое применение правда не в таком
> масштабе и не настолько цельная. Возьмем например Exchange Server или
> Lotus - вот и хранилища с одной стороны. Храни что хочешь - данные,
> файлы, программы и т.д. Возьмем ext2fs или наработки на ней (если не
> ошибаюсь), где уже есть что-то напоминающее протоколирование
> изменений. Возьмем такую фенечку как Shadow Copy в Server 2003, где
> можно восстановить конкретный файл на определённый момент времени.
> 
> Конечно, разработка мощной БД наподобие Oracle, Sybase или хоша Sql
> Server - вещь чрезвычайно сложная, да и не нужная в контексте ОС. Если
> не особо напираеть на супер быстродействие, и отбросить другие не
> очень нужные вещи (триггеры и т.д.), то задача сведётся в следующему:
> Формализация языка запросов (Можно использовать SQL? или разработать
> свой простенький язык), организация хранения данных - д.б. программный
> модуль, который просто управляет, размещением таблиц на физическом
> носителе и протоколирует все изменения в этих таблицах в лог файле
> (кстати д.б. программный модуль, который управляет самим лог-файлом)и
> модуль, управляйщий  выборкой и поиском нужных данных. Реализовать
> простое индексирование данных совсем не сложно. Надо также разработать
> библиотеку, которую используют программы пользователя для работы с
> данными. Допустим реализовать функцию open, которая преобразует вызов
> в запрос к движку хранилища. Все это, если грамотно спланировать
> можно, думаю, реализовать в течение 1.5 - 2 месяцев.

Outro

На сегодня все, уважаемые подписчики.
Как всегда, мой почтовый ящик открыт для вас: lonesome@lowlevel.ru
Также вы можете задавать интересующие вас вопросы в форуме lowlevel.ru
Предыдущие выпуски рассылки вы можете найти по этому адресу:
http://subscribe.ru/archive/comp.soft.prog.osdev
А все, исходники, опубликованые в рассылке, располагаются здесь:
http://www.lowlevel.ru/osdev/sources.htm
Всего наилучшего!
Lonesome


ПРЕДЫДУЩИЙ ВЫПУСК      СЛЕДУЮЩИЙ ВЫПУСК


Rambler's Top100