Структура, состав и назначение подсистем типовой системы программирования (Visual Studio или Delphi)

Классификация операционных систем

1. Однозадачные и многозадачные

2. Однопользовательские и многопользовательские

3. Однопроцессорные и многопроцессорные системы

4. Локальные и сетевые.

По числу одновременно выполняемых задач операционные системы делятся на два класса:

1. Однозадачные (MS DOS)

2. Многозадачные (OS/2, Unix, Windows)

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

В зависимости от областей использования многозадачные ОС подразделяются на три типа:

1. Системы пакетной обработки (ОС ЕС)

2. Системы с разделением времени (Unix, Linux, Windows)

3. Системы реального времени (RT11)

количеству одновременно работающих пользователей: однопользовательские, многопользовательские;

числу процессов, одновременно выполняемых под управлением системы: однозадачные, многозадачные;

количеству поддерживаемых процессоров: однопроцессорные, многопроцессорные;

разрядности кода ОС: 8-разрядные, 16-разрядные, 32-разрядные, 64-разрядные;

типу интерфейса: командные (текстовые) и объектно-ориентированные (графические);

 

Проце́сс — программа (и все её элементы: адресное пространство, глобальные переменные, регистры, стек, открытые файлыи т. д. ), которая выполняется в текущий момент. Стандарт ISO 9000:2000 определяет процесс как совокупность взаимосвязанных и взаимодействующих действий, преобразующих входящие данные в исходящие. Компьютерная программа сама по себе — это только пассивная совокупность инструкций, в то время как процесс — это непосредственное выполнение этих инструкций.

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

Модели: однопоточные, многопоточные.

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

Контекст потока

программный счетчик, регистр состояния и содержимое остальных регистров процессора;

указатели на стек ядра и пользовательский стек;

указатели на адресное пространство, в котором выполняется поток (каталог таблиц страниц процесса).

Модели потока

1:1 (потоки выполнения на уровне ядра)

Потоки выполнения, созданные пользователем в модели 1-1, соответствуют диспетчируемым сущностям ядра. Это простейший возможный вариант реализации потоковости. В Windows API этот подход использовался с самого начала. В Linux обычная библиотека C реализует этот подход (через библиотеку потоков POSIX, а в более старших версиях через LinuxThreads). Такой же подход используется ОС Solaris,NetBSD и FreeBSD.

N:1 (потоки выполнения уровня пользователя)

В модели N:1 предполагается, что все потоки выполнения уровня пользователя отображаются на единую планируемую сущность уровня ядра, и ядро ничего не знает о составе прикладных потоков выполнения. При таком подходе переключение контекста может быть сделано очень быстро, и, кроме того, он может быть реализован даже на простых ядрах, которые не поддерживают многопоточность. Однако, одним из главных недостатков его является то, что в нём нельзя извлечь никакой выгоды из аппаратного ускорения на многопоточных процессорах или многопроцессорных компьютерах, потому что только один поток выполнения может быть запланирован на любой момент времени. Эта модель используется в GNU Portable Threads.

M:N(смешанная потоковость)

В модели M:N некоторое число N прикладных потоков выполнения отображаются на некоторое число M сущностей ядра или «виртуальных процессоров». Модель является компромиссной между моделью уровня ядра («1:1») и моделью уровня пользователя («N:1»). Вообще говоря, «M:N» потоковость системы являются более сложной для реализации, чем ядро или пользовательские потоки выполнения, поскольку изменение кода как для ядра, так и для пользовательского пространства не требуется. В M:N реализации библиотека потоков отвечает за планирование пользовательских потоков выполнения на имеющихся планируемых сущностях. При этом переключение контекста потоков делается очень быстро, поскольку модель позволяет избежать системных вызовов. Тем не менее, увеличивается сложность и вероятность инверсии приоритетов, а также неоптимальность планирования без обширной (и дорогой) координации между пользовательским планировщиком и планировщиком ядра.

Планирование:

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

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

Создание, завершение, наследование дескрипторов

Приложение, или, как часто его называют, программа, – это статическая последовательность команд. При запуске программы в ОС Win32 создается отдельный процесс (process), или, как его иногда называют, задача (task). Процесс состоит из:

· исполняемой программы с ее кодом и данными;

· виртуального адресного пространства (address space), представляющего собой набор адресов виртуальной памяти, доступных для процесса;

· ресурсов, выделяемых процессу;

· как минимум одного потока, именуемого потоком управления (thread of execution), или главным потоком процесса. Именно поток управления и требует от операционной системы времени на обслуживание процесса.

В момент запуска задачи ОС создает дескриптор – специальную структуру, описывающую стартующий процесс. Дескриптор процесса содержит информацию, позволяющую Win32 управлять процессом. В частности в дескрипторе хранится:

· идентификатор процесса (PID – process identificator);

· информация о ресурсах, которыми владеет или собирается завладеть процесс;

· данные о приоритете процесса;

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

За один и тот же интервал времени, называемый квантом времени, один процессор реально может выполнять не более одной задачи. Вместе с тем многозадачная (multitasking) ОС вполне способна одновременно обслуживать несколько процессов. Это достигается благодаря переключению процессора компьютера с исполнения одной задачи на другую. Такое переключение называется переключением контекста (context switching). При этом важно помнить, что время выделяется не процессу, а принадлежащим ему потокам. И чем выше производительность процессора, тем более правдоподобна иллюзия одновременного выполнении нескольких программ.

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

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

· Признак доступа

· Устройство связи

· Консольный ввод данных

· Экранный буфер консоли

· Рабочий стол

· Каталог

· Событие

· Файл

· Файл, отображаемый в памяти

· Задание

· Почтовый ящик в ядре системы

· Мьютекс

· Канал

· Процесс

· Ключ системного реестра

· Семафор

· Сокет

· Поток

· Таймер

· Режим оконного терминала

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

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

Система повышает приоритет только тех потоков, базовый уровень которых находится в пределах 1-15 Именно в связи с этим данный диапазон принято называть ʼʼ областью динамического приоритета ʼʼ (dynamic priority range). Система не допускает динамического повышения приоритета потока до уровней реального времени (более 15) Поскольку потоки с такими уровнями обслуживают системные функции, это ограничение не дает приложению нарушить работу операционной системы.

 

Структура, состав и назначение подсистем типовой системы программирования (Visual Studio или Delphi).

Система программирования представляет собой совокупность средств разработки программ (языки программирования, текстовые редакторы, трансляторы, редакторы связей, библиотеки подпрограмм, утилиты и обслуживающие программы), обеспечивающих автоматизацию составления и отладки программ, подготовку соответствующей документации. Как правило, включает не эталонный вариант языка, а его версию, содержащую определенные упрощения иди расширения. Некоторые системы программирования могут поддерживать разработку программ на нескольких языках. Наиболее известные системы программирования для персональных компьютеров: Visual Studio, созданная фирмой Microsoft, поддерживающая языки программирования Бейсик, Java, C++; Delphi.

Типовая система программирования состоит из следующих компонент:

· язык программирования – семантическая система описания алгоритмов или иных действий по обработке информации;

· транслятор (интерпретатор или компилятор) – обработчик языка программирования, переводящий символические директивы на язык машинных кодов;

· библиотека стандартных программ и функций – совокупность отлаженных программных модулей, вызываемых из пользовательской программы для выполнения стандартных действий;

· средства трассировки (отладки), текстовый редактор и ряд других служебных утилит.

 

Взаимодействие приложений — реализация с помощью COM, ActiveX, обмена сообщениями (основные принципы). Причины возникновения большого числа таких технологий (в т.ч. LPC, DPC, APC) и имеющиеся проблемы. Краткая характеристика известных технологий организации взаимодействия ПО.

 

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

COM - это не язык программирования, а подход (спецификация) к созданию программ, обеспечивающий взаимодействие программ любых типов. Компоненты COM объединяются друг с другом для создания приложений или систем компонентов. Компоненты можно менять во время выполнения, без перекомпиляции или перекомпоновки приложения. COM - это основа, на которой построены такие технологии Microsoft, как ActiveX, DirectX и OLE.

Таким образом, ключевое слово при использовании COM - компонент. К компонентам обычно предъявляются следующие требования:

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

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

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

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

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

 

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

Как и большинство технологий, обмен сообщениями характеризуется несколькими базовыми концепциями (шаблонами):

· Каналы. Приложения, объединенные с помощью технологии обмена сообщениями, передают данные по каналам сообщений . Изначально система обмена сообщениями не содержит каналов; они создаются по мере определения способов взаимодействия приложений.

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

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

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

· Преобразование. Зачастую отправитель и получатель используют различные форматы для представления одних и тех же данных. Для преобразования формата отправителя в формат получателя сообщение должно пройти через промежуточный фильтр, получивший название транслятор сообщений .

· Конечные точки. Большинство приложений не обладает встроенными средствами интеграции. Для подключения таких приложений к системе обмена сообщениями необходим промежуточный код, учитывающий особенности приложения и системы обмена сообщениями. Этот код является совокупностью конечных точек сооб щения , позволяющих приложению отправлять и принимать сообщения.

 

Появление подобных технологий (в т.ч. LPC(local procedure call), DPC(англ. Deferred procedure call — отложенный вызов процедуры) , APC(asynchronous procedure call)) обусловлено развитием многозадачных ОС и многопоточных процессов.