Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
СПиОС.doc
Скачиваний:
3
Добавлен:
07.07.2019
Размер:
252.42 Кб
Скачать
  1. CreateSemaphore();

  2. OpenSemaphore( DWORD dwDesiredAccess, // флаги доступа                BOOL bInheritHandle, // флаги наследования                LPCTSTR lpName // указатель на имя семафора );

Чтобы перевести семафор в свободное состояние (увеличить счетчик ресурсов), необходимо вызвать функцию:

BOOL ReleaseSemaphore( HANDLE hSemaphore, // описатель объекта "семафор"                        LONG lReleaseCount, // определяет, на сколько увеличиться счетчик ресурсов                        LPLONG lpPreviousCount // предыдущее значение счетчика );

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

Объекты "события " бывают двух типов:

  1. со сбросом вручную;

  2. с автосбросом.

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

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

HANDLE CreateEvent( LPSECURITY_ATTRIBUTES lpEventAttributes, // указатель на атрибуты защиты                     BOOL bManualReset, // флаг для события со сбросом вручную                     BOOL bInitialState, // флаг для начального состояния                     LPCTSTR lpName // указатель на имя объекта "событие" );

Потоки из других процессов могут получить доступ к этому объекту тремя способами:

  1. вызовом функции CreateEvent с тем же именем события;

  2. применением функции DuplicateHandle;

  3. вызовом функции OpenEvent        HANDLE OpenEvent( DWORD dwDesiredAccess, // флаги доступа                       BOOL bInheritHandle, // флаги наследования                       LPCTSTR lpName // указатель на имя объекта "событие" );

Закрытие события осуществляется функцией CloseHandle().

  1. Многозадачность. Распределение времени с вытеснением. Очереди потока и обработка сообщений. Архитектура очередей сообщений в Win32.

Многозадачность. Очереди потока и обработка сообщений.

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

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

  1. синхронная;

  2. асинхронная.

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

Рассмотрим архитектуру очередей сообщений в Win32. Всякий раз при создании потока система создает структуру THREADINFO и связывает ее с этим потоком. Эта структура не документирована и включает следующее:

  1. очередь асинхронных сообщений потока (posted message queue);

  2. очередь синхронных сообщений потока (sent message queue);

  3. очередь ответных сообщений (reply message queue);

  4. виртуальная очередь ввода (virtualized input queue);

  5. флаги пробуждения.

Сообщение ставится в очередь асинхронных сообщений функцией:

BOOL PostMessage( HWND hWnd, // описатель окна, куда посылаем сообщение                   UINT Msg, // сообщения                   WPARAM wParam, // первый параметр сообщения                   LPARAM lParam // второй параметр сообщения );

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

Посылка синхронных сообщений:

LRESULT SendMessage( HWND hWnd,                      UINT Msg,                      WPARAM wParam,                      LPARAM lParam  );

Это сообщение отправляется непосредственно оконной процедуре. Оконная функция обработает сообщение и возвратит результат. SendMessage вернет управление только после того, как оконная процедура обработает сообщение.

  1. Создание DLL. Проецирование DLL на адресное пространство процесса. Функция входа-выхода. Экспорт функций и переменных из DLL.

DLL – набор автономных функций, которыми могут пользоваться исполняемые файлы или другие dll.В dll содержатся все функции интерфейса Win32API. USER32/DLL – Создание окон, передача сообщений пользовательскому интерфейсу. GDI32/DLL – Графика, вывод текста.

Создание DLL.

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

Когда поток вызывает из DLL какую-то функцию, та считывает свои параметры из стека потока и размещает в этом стеке собственные локальные переменные. Кроме того, любые созданные кодом DLL объекты принадлежат созданному потоку или процессу (DLL ничем не владеет).

Неявная компоновка.

При сборке приложения компоновщику необходимо указать набор LIB-файлов. Каждый такой файл содержит список функций данной DLL, вызов которых разрешен (экспортирование элементов из DLL).

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

Поиск DLL осуществляется в:

каталоге, содержащем EXE-файл; текущем каталоге процесса; системном каталоге Windows; основном каталоге Windows; каталогах, указанных в переменных окружения path.

Если DLL не найден, система закрывает окно и завершает процесс.Библиотеки DLL, спроецированные на адресное пространство этим методом, не отключаются от него до завершения процесса.Явная компоновка. – dll не проецируется при загрузке, но в опр момент вызываются ф-ии LoadLibrary, либо LoadLibraryEx.

Обе ф-ции ищут образ файла DLL в тех же каталога , что и при неявной компоновке . При сборке в двоичный файл DLL встраивается адрес ф-ции входа-выхода (DllMain) .Когда ваша Dll проецируется на адресное пространство процесса , то она на самом деле она вызывает _DllMainCRTStartUp, а не нашу DllMain.Она инициализирует станд.библиотеку и конструирует все глобальные и статические С++ объекты , и лишь после этого она вызывает вашу DllMain.

Вызывается в 4-х случаях :

1) При проэц-ии DLL на адресное пространство процесса

2) При отключении от адр.-го пространства процесса

3) При создании в процессе нового потока

4) При завершении работы потока

Экспорт функций и переменных из DLL

_ _dedspec(dll export) int Add (int nLeft, int nRight) {return (nLeft+nRight);

_ _dedspec(dll export) int g_n UserCount=0;

Компилятор встраивает в конечный obj – файл дополнительную информацию необходимую компоновщику при сборке DLL из obj – файла. Обнаружив ее компоновщик создает lib-файл со списком идентификаторов экспортируемых из DLL. Этот lib-файл нужен при сборке любого exe-файла, вызываемого функ-ей из данной DLL. Компоновщик встраивает в конечный файл DLL таблицу экспортируемых идентификаторов. Каждый элемент в этой табл. Содер-т имя экспор-ой функ-ии или переменной, а так же ее адрес внутри DLL файла.

Импорт из DLL

Чтобы exe мог вызывать ф-ии из dll х нужно описать следующим образом.

_ _dedspec(dll import) int Add(int nLeft, int nRight);

_ _dedspec(dll import) int g_n UserCount;

Компилятор генерирует спец код для импортируемых идентификаторов и встроит спец инф в obj файл. Эта информация подсказывает компановщику, какие ф-ии необходимо искать в lib-файлах. Таблица импорта вносится в конечный exe файл при записи его на жёсткий диск.

  1. Основы архитектуры СОМ. Интерфейсы СОМ. Автоматизация OLE.

Основы архитектуры COM.

Все технологии OLE и ActiveX построены на основании, обеспеченном СОМ.

Рассмотрим следующую проблему : одна часть программного обеспечения должна получить доступ к сервисам, предоставляемым другой частью. Но в каждом отдельном случае механизм доступа разный: вызовы локальных функций, передача сообщения средствами связи между процессами, системные вызовы  п или какая-то разновидность сетевых коммуникаций. Зачем все это? Не проще ли определить один общий способ доступа ко всем видам программных сервисов независимо от способа их реализации?Этим и занимается СОМ. Она определяет стандартный механизм, с помощью которого одна часть программного обеспечения предоставляет свои сервисы другой и который работает во всех описанных выше случаях. Общая архитектура сервисов в библиотеках, приложениях, системном и сетевом программном обеспечении позволяет СОМ изменить подход к созданию программ.Интерфейс – это список ф-й с точки зрения двоичного кода – это таблица, содержащая указатели на ф-ии. Реализуемые ф-ии создают серверную таблицу с указателями на них, а указатели на эту таблицу м.б. получены клиентом.. Именно через эти указатели клиент получает доступ к ф-ии сервера. Каждый интерфейс имеет уникальный GUID. В названии интерфейса – англ буквы и _. Все интерфейсы явл наследниками Iunknown , кот имеет 3 ф-ии(метода): 1) addRet – увеличить на 1 число ссылок на объект. 2) Release – уменьшить на 1 число ссылок на объект. 3) QueryInterface – для получения указателяна интерфейс.

Можно применять язык IDL для описания интерфейса. MIDL – компилятор, ATL – библиотека.

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

Большинство объектов СОМ поддерживают более одного интерфейса. Сам объект всегда реализуется внутри некоторого сервеpa. Сервер может быть либо динамически подключаемой библиотекой (DLL), подгружаемой во время работы приложения, либо отдельным самостоятельным процессом.

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

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

Автоматизация OLE(Object Linking and Embedding).

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

  1. Архитектура UNIX. Ядро системы. Файловая система. Типы файлов.

Архитектура UNIX.UNIX- это многопользовательская и многозадачная операционная система. Архитектура ее базируется на наборе интуитивно ясных понятиях:

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

- интерфейс пользователя - способ взаимодействия пользователя с системой UNIX(обычно командный интерпретатор).

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

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

- перенаправление ввода/вывода гибкий механизм ввода-вывода системы.

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

Структура файловой системы. Файловая система ОС UNIX имеетиерархическую структуру, образующую дерево каталогов и файлов. Корневой каталог обозначается символом "/", путь по дереву каталогов состоит из имен каталогов,разделенных "/", например:/usr/work/document. Имя файла содержит путь. Имя явл атрибутом файловой системы, а не набором некоторых данных на диске. В каждый момент времени с любымпользователем связан текущий каталог, то есть местоположение пользователя виерархической файловой системе.

Каждый файл имеет связь с несколькими метаданными, хрянящимися в inode.

Каждый файл ОСUNIX может быть однозначно специфицирован некоторой структурой данных,называемой описателем файла или дескриптором. Он содержит всю информацию о файле: тип файла, режим доступа, идентификатор владельца, размер, адрес файла, даты последнего доступа и последней модификации, дату создания и пр. Эта структура описана в файле<fcntl.h>, она занимает 64 байта и содержит следующую информацию:

struct dinode { unsigned shortdi_mode;/* режим доступа и тип файла */

shortdi_nlink; /* счетчик числа ссылокна файл */

shortdi_uid; /* идентификатор еговладельца */

shortdi_gid; /* идентификатор группы*/

off_tdi_size; /* счетчик числа байт вфайле */

chardi_addr[40]; /* указатели на блокидиска,в которыххранится сам файл */

time_tdi_atime; /* дата последнего доступа*/

time_tdi_mtime; /* дата последней модификацииметаданных*/

time_tdi_ctime; /* дата создания */ }

Поле di_mode состоит из 16-тиразрядов. Поле di_addr используется для хранения указателей местоположения блоков диска, содержащих информацию, помещенную в данный файл. В этом поле может храниться 13 указателей, из которых первые 10 относятся к первым десяти блокам файла. Если файл занимает больше места, то в 11-й указатель заносится информация о местоположении первичногоблока косвенности, состоящего из 128 32-битных указателей наблоки файла; 12-й указатель указывает на вторичный блок косвенности, содержащий128 указателей местоположения первичных блоков косвенности, а 13-й указатель,соответственно, указывает на местоположение третичного блока косвенности,включающего 128 указателей вторичного блока косвенности. Таким образом,используя эту схему адресации, можно обращаться к файлу, состоящему не более чем из (128x128x128+128x128+128+10) блоков. Все этирассуждения справедливы для блоков размером 512 (128x4) байт.

Обращение к файлу происходит по имени. Локальное имя файла представляет собой набор произвольных символов. Если среди этих символов встречается точка, то за ней следует т.н. расширение, которое обычно служит для определения типа файла. Расширений м.б. несколько (например, имя "progr.c.b" может означать старую версию (bak-файл) программы на языке С).

Локальное имя файла хранится в соответствующем каталоге. Путь к файлу от корневого каталога называется полным именем файла. Если обращение к файлу начинается с символа "/",то его поиск начинается с корневого каталога, в любом другом случае поиск файла начинается с текущего каталога.

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

     Обращение к файлу происходит по имени. Локальное имя файла представляет собой набор символов. В качестве символов следует использовать цифры, буквы латинского алфавита и символ ‘_’. Локальное имя файла хранится в соответствующем каталоге. Каталог – файл, содержащий имена. Путь к файлу от корневого каталога называется полным именем файла.

Типы файлов

В ОС UNIX сущ 6 типов файлов:обычные файлы, каталоги, специальные файлы, каналыFIFO, символьные связи link, сокеты..

Обычный файл (regular file) представляет собой последовательность байтов. Никаких ограничений на файл системой не накладывается, и никакого смысла не приписывается его содержимому: смысл байтов зависит исключительно от программ, обрабатывающих файл.

Каталог - это файл особого типа, отличающийся от обычного файла наличием структуры и ограничением по записи: осуществить запись в каталог может только ядро ОС UNIX. Каталог устанавливает соответствие между файлами (точнее, номерами описателей) и их локальнымиименами. Пример каталога для файловой системы ОС UNIX System V - Рис.1 (2 байта- номера описателей, 14 байтов -локальные имена).

Номер описателя

Имя файла

5412

81

3009

58

3413

0

3601

.

..

bin

work

text.txt

cross.c

move.c

Рисунок 1. Пример каталога ОСUNIX System V

Номер описателя, соответствующий имени ".",- это ссылка на файл, в котором содержится информация о самом каталоге. Номер описателя, соответствующий имени "..", - это ссылка на родительский каталог текущего каталога. Совокупность всех каталогов специфицирует структуру файловой системы в целом.

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

Канал - это программное средство, связывающее процессы ОС UNIX буфером ввода/вывода. Например, запуск процессов ввиде $ процесс_1 | процесс_2 означает, что стандартный вывод процесса_1 будет замкнут на стандартный ввод процесса_2. При этом сначала создается канал, а потом на выполнение одновременно запускаются оба процесса, и общее время их выполнения определяется более медленным процессом.

Символьная связь – позволяет косвенно адресовать файл. Данные файла, являющегося символьной связью, содержат только имя целевого файла.

Классы доступа user access(u); group access(g); other access(o).

Типы прав доступа – read (r); write (w); execute (x).

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

  1. Командный интерпретатор shell. Общий синтаксис скрипта. Переменные. Команды, функции и программы. Условные выражения.

Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]