Показаны сообщения с ярлыком операционные системы. Показать все сообщения
Показаны сообщения с ярлыком операционные системы. Показать все сообщения

понедельник, 22 декабря 2008 г.

Откуда есть пошли операционные системы, и что это вообще такое?

Давайте посмотрим с высоты нашего третьего тысячелетия на вычислительные машины пятидесятых годов прошлого века. Громоздкие, занимавшие целые здания, они управлялись множеством кнопочек, рычажков и переключателей, с помощью которых оператор мог загрузить программу с перфокарт (или с каких-нибудь других носителей) и управлять действиями компьютера. Оператор ЭВМ представлял собой как бы "живую" операционную систему; он заботился о следующем:

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

В сущности, все современные операционные системы выполняют такие же функции, как и наш воображаемый оператор ЭВМ 50-х годов прошлого века. Они точно так же распределяют ресурсы компьютера и предоставляют пользователю (а еще явственнее - программисту) развитые средства взаимодействия с компьютером (например в Windows окно с сообщением можно создать при помощи системной функции MessageBoxA или MessageBoxU, хотя на самом деле процессор (да и все другое аппаратное обеспечение) даже не имеют представления о том, что такое окно. Максимум, что они могут - это выводить разноцветные точки в нужных местах экрана. Но ведь прикладному программисту даже не нужно знать, что происходит под капотом системы!)

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

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

среда, 17 декабря 2008 г.

TinyOS

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

TinyOS заметно отличается от ОС общего назначения, таких как UNIX, Windows и пр. Например, приложения для БСС не являются интерактивными в том же смысле, что и приложения для обычных ПК. Это объясняется тем, что TinyOS не нуждается во встроенной поддержке пользовательского интерфейса. К тому же ограничения в ресурсах памяти, с одной стороны, и аппаратная поддержка распределения памяти — с другой, делают такие механизмы, как виртуальная память, ненужными или даже невозможными в реализации.

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

Архитектура TinyOS включает две главные функциональные составляющие: планировщик задач и компонент. Понятие «компонент» в TinyOS несколько отличается от общепринятого. Так, интерфейс компонента TinyOS состоит из двух частей: верхней (upper), предоставляемой этим компонентом как провайдером, и нижней (lower), требуемой для его функционирования. Обе части содержат описания команд и событий.

Компонент имеет два основных элемента: набор команд и набор обработчиков событий. Кроме того, в каждом компоненте объявляются события, о которых он сигнализирует, и команды, используемые данным компонентом. Эти объявления применяются при компоновке для формирования конфигурации системы, настроенной на определенный класс приложений. Процесс компоновки распределяет компоненты по уровням, где каждый более высокий уровень посылает команды нижележащему уровню, а тот, в свою очередь, обращается к более высокому уровню с помощью сигналов о событиях. Аппаратное обес печение является самым нижним уровнем в иерархии компонентов.

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

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

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

Как и в остальных ОС, в TinyOS существуют атомарные потоки (task), которые выполняются вплоть до своего завершения, хотя и могут быть вытеснены событиями. С компонентом может быть связано более одного потока. Потоки могут вызывать команды нижележащего уровня, сигнализировать о событиях более высокому уровню и планировать другие потоки внутри компонента. Семантика потока «выполнение вплоть до завершения» позволяет иметь один стек, который выделяется выполняющемуся в данный момент потоку, что очень важно в системах с ограниченной памятью. Потоки дают возможность имитировать параллельную обработку внутри каждого компонента, так как они выполняются асинхронно по отношению к событиям. Однако потоки не должны блокироваться или простаивать в ожидании, поскольку в таких случаях они будут препятствовать развитию обработки в других компонентах.

Операционка от Microsoft

Singularity - очень интересная разработка от Microsoft, они написали полную систему с нуля едином адресном пространстве на модели безопасного языка. Они придумали этот новый язык, Sing#, который произошел от c#, в Sing#, как и Java вы не можете просто написать p= random & *p=0, язык вам просто этого не позволит.

Это безопасный язык, Он сильно ограничивает вас в том, что вы можете сделать, и все компоненты взаимодействуют друг с другом в едином адресном пространстве через "именованные потоки (named pipes)"

Поток имеет протокол, и этот протокол описан на формальном языке - вы посылаете сообщение кому-нибудь этого типа. И они посылают обратно от A, B или C и т.д.

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

Таким образом, они получили очень правильную систему, так как заставляют описать какой протокол нужен для всех этих вещей.

Это очень интересная разработка, они заставили её рабтать, таким образом, это интересный подход. Она не совместима с Windows, она не совместима с Unix, она не совместима ни с чем, это будет маркетинговой проблемой для них.

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

Интерьвью с Эндрю Танненбаумом (разработчик Minix, учитель Линуса)

Все серии SembianOS