Главная | Обратная связь | Поможем написать вашу работу!
МегаЛекции

Не синхронизированный. Схема примерно та же.




Пример: 4 диска данных, один – четности:

 

Изначально для любого бита:

 

X4(i)=X3(i)XOR X2(i)XOR X1(i)XOR X0(i)

 

После обновления полосы на диске X1:

X4new(i)=X4(i)XOR X1(i)XOR X1new(i)

 

RAID 5 (распределенная четность – циклическое распределение «четности»)

 

циклическое распределение контрольного диска

 

RAID 6 (двойная избыточность – циклическое распределение четности с использованием двух схем контроля: N+2 дисков)

 

 

 

OC Unix: Работа с внешними устройствами

 

Файлы устройств, драйверы

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

В системе существуют два типа специальных файлов устройств:

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

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

Следует отметить, файловая система может быть создана только на блок-ориентированных устройствах.

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

тип файла устройства – байт-ориентированный или блок-ориентированный;

«старший номер» (major number) устройства - номер драйвера в соответствующей таблице драйверов устройств;

«младший номер» (minor number) устройства – служебная информация, передающаяся драйверу устройства.

 

Система поддерживает две таблицы драйверов устройств.

bdevsw – таблица драйверов блок-ориентированных устройств.

cdevsw - таблица байт-ориентированных устройств.

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

В качестве примера, рассмотрим типовой набор точек входа в драйвер (b - префикс точки входа, характеризующий конкретный драйвер):

bopen() открытие устройства, обеспечивается инициализация устройства и внутренних структур данных драйвера;

bclose() закрытие драйвера устройства, например в том случае, если ни один из процессов не работает с драйвером;

bread() чтение данных;

bwrite() запись данных;

bintr() – обработка прерывания, вызывается ядром при возникновении прерывания в устройстве с которым ассоциирован драйвер;

 

В системе возможно обращение к функциям драйвера в следующих ситуациях:

1. старт системы, определение ядром состава доступных устройств.

2. обработка запроса ввода/вывода (запрос может быть инициирован, любыми процессами, в том числе и ядром);

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

4. выполнение специальных команд управления (например, остановка устройства, приведение устройства в некоторое начальное состояние и т.п.).

 

 

Включение/удаление драйверов в систему

Существует два, традиционных способа включения драйверов новых устройств в систему:

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

за счет динамического включения драйвера в систему.

 

Динамическое включение драйверов в систему предполагает выполнение следующей последовательности действий:

загрузка и динамическое связывание драйвера с кодом ядра (выполняется специальным загрузчиком);

инициализация драйвера и соответствующего ему файла;

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

 

Организация обмена данными с файлами

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

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

 

ассоциированные с процессом;

ассоциированные с ядром операционной системой.

Таблица индексных дескрипторов открытых файлов.

 

Для каждого открытого в рамках системы файла формируется запись в таблице ТИДОФ, содержащая:

 

копия индексного дескриптора (ИД) открытого файла;

кратность - счетчик открытых в системе файлов, связанных с данным ИД.

 

 

Таблица файлов.

Таблица файлов содержит сведения о всех файловых дескрипторах открытых в системе файлов. Каждая запись ТФ соответствует открытому в системе файлу или точнее используемому файловому дескриптору (ФД). Каждая запись ТФ содержит указатели чтения/записи из/в файл. Рассмотрим правила установления соответствия между открытыми в процессах файлами и записями ТФ. При каждом новом обращении к функции открытия файла в таблице процессов образуется новая запись, таким образом если неоднократно в одном или нескольких процессах открывается один и тот же файл, то в каждом случае будет определяться свой независимый от других файловый дескриптор, в том числе со своим указателем чтения/записи. Если файловый дескриптор в процессе образуется за счет наследования, то в этом случае новые записи в ТФ не образуются, а происходит увеличение счетчика «наследственности» в записи, соответствующей файлу, открытому в прародитель

 

Таблица открытых файлов.

С каждым процессом связана таблица открытых файлов (ТОФ). Номер записи в данной таблице есть номер ФД, который может использоваться в процессе. Каждая строка этой таблицы имеет ссылку на соответствующую строку ТФ

 

Для иллюстрации работы с данными таблицами рассмотрим следующий пример.

 

 

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

Далее, формируется процесс №2, который в свою очередь открывает файл с именем name, в результате чего в ТФ будет образована новая запись, которая будет ссылаться на запись ТИДОФ, соответствующую индексному дескриптору файла name, счетчик кратности этой записи увеличится на единицу.

Процесс №1 выполняет системный вызов fork() в результате чего образуется процесс №3 с открытым (унаследованным) файлом name. В таблице ТОФ№3 будет размещена копия таблицы ТОФ№2, счетчик наследственности соответствующей записи ТФ и счетчик кратности в записи ТИДОФ увеличатся на единицу.

 

Буферизация при блок-ориентированном обмене

 

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

 

 

Лекция 10. Система межпроцессного взаимодействия IPC

 

По правам доступа можно выделить следующие виды вз-я:

Симметричное, когда все процессы имеют одинаковые права (например, каналы или сигналы);

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

 

По тому, кто может участвовать во взаимодействии:

в пределах одной локальной системы;

в пределах компьютерной сети.

 

Понятно, что в сети взаимодействующие процессы именуются по IP адресам, но как их именовать в пределах локальной машины?

использовать идентификатор процесса, но это накладывает ряд ограничений:

1) надо знать этот идентификатор (а он связывается с конкретным процессом лишь в момент его появления в системе);

2) недетерминированность (номера случайны);

3) все вз-щие процессы должны участвовать в процессе;

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

именованные каналы (можно обращаться как к файлу в произвольное машинное время).

 

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

Выделяют следующие разделяемые ресурсы:

1) «очередь сообщений»;

2) разделяемая память;

3) Семафоры.

 

4)

 

Каждый IPC ресурс обладает набором атрибутов, среди них:

атрибут владельца ресурса (эффективный идентификатор процесса, создавшего ресурс);

права доступа к нему (запись \ чтение).

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

 

 

Как сгенерировать такой уникальный ключ?

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

Для решения этой задачи служит функция ftok():

#include <sys/types.h>

 

#include<sys/ipc.h>

key_t ftok (char *filename, char proj)

где filename –имя существующего в ФС файла и его атрибутыж

 

proj – некоторая буква, которая позволяет генерировать разные значения ключа по одному и тому же значению первого параметра – строки.

 

 

Эта функция генерирует значение ключа по некоторой строке символов и добавочному символу (букве), передаваемым в качестве параметров. Гарантируется, что полученное таким образом значение будет отличаться от всех других значений, сгенерированных функцией ftok() с другими значениями параметров, и в то же время, при повторном запуске ftok() с теми же параметрами, будет получено то же самое значение ключа. Если же файл удалить из ФС, а затем создать новый с тем же именем, вызвать ftok() с тем же параметром, то гарантированно создастся другое имя, т.к. например, учитывается файловый дескриптор.

Следует заметить, что функция ftok() не является системным вызовом, а предоставляется библиотекой.

 

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

Ели указано значение IPC_PRIVATE, создается ресурс, который будет доступен только породившему его процессу. Такие ресурсы обычно порождаются родительским процессом, который затем сохраняет полученный дескриптор в некоторой переменной и порождает своих потомков. Т.к. потомкам доступен уже готовый дескриптор созданного объекта, они могут непосредственно работать с ним, не обращаясь предварительно к «get»- методу. Таким образом, созданный ресурс может совместно использоваться родительским и порожденными процессами. Однако если один из этих процессов повторно вызовет «get»- метод с ключом IPC_PRIVATE, в результате будет получен другой, совершенно новый разделяемый ресурс, т.к. при обращении к «get»- методу с ключом IPC_PRIVATE всякий раз создается новый объект нужного типа.

 

Если при обращении к «get»- методу указан ключ, отличный от IPC_PRIVATE, происходит следующее:

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

 Если объект с заданным ключом не найден, и среди переданных флагов отсутствует флаг IPC_CREAT, «get»- метод вернет –1, а в переменной errno будет установлено значение ENOENT

 

 Если объект с заданным ключом найден среди существующих, «get»- метод вернет дескриптор для этого существующего объекта, т.е. фактически, в этом случае происходит подключение к уже существующему объекту по заданному ключу. Если процесс ожидал создания нового объекта по указанному ключу, то для него такое поведение может оказаться нежелательным, т.к. это будет означать, что в результате случайного совпадения ключей (например, если процесс не использовал функцию ftok()) он подключился к чужому ресурсу. Чтобы избежать такой ситуации, следует указать в параметре флагов наряду с флагом IPC_CREAT и правами доступа еще и флаг IPC_EXCL – в этом случае «get»- метод вернет -1, если объект с таким ключом уже существует (переменная errno будет установлена в значение EEXIST)

 Следует отметить, что при подключении к уже существующему объекту дополнительно проверяются права доступа к нему. В случае, если процесс, запросивший доступ к объекту, не имеет на то прав, «get»- метод вернет –1, а в переменной errno будет установлено значение EACCESS

 

Нужно заметить, что для каждого типа объектов IPC существует некое ограничение на максимально возможное количество одновременно существующих в системе объектов данного типа. Если при попытке создания нового объекта окажется, что указанное ограничение превышено, «get»- метод, совершавший попытку создания объекта, вернет -1, а в переменной errno будет указано значение ENOSPC.

 

 

«Очередь сообщений»

Очередь сообщений – организованная совокупность типизированных сообщений, организованное по принципу FIFO. Имеет 2 поля:

тип сообщения;

тело сообщения, представляющее собой некоторое целое число.

Благодаря наличию типов сообщений, очередь можно интерпретировать двояко — рассматривать ее либо как сквозную очередь неразличимых по типу сообщений,

либо как некоторая совокупность подочередей, каждая из которых

содержит элементы определенного типа

 

Извлечение сообщений из очереди происходит согласно принципу FIFO – в порядке их записи, однако процесс-получатель может указать, из какой подочереди он хочет извлечь сообщение, или, иначе говоря, сообщение какого типа он желает получить – в этом случае из очереди будет извлечено самое «старое» сообщение нужного типа.

 

Рассмотрим набор системных вызовов, поддерживающий работу с очередями сообщений.

 

1) Доступ к очереди сообщений.

#include <sys/types.h>

 

#include <sys/ipc.h>

 

#include <sys/message.h>

Поделиться:





Воспользуйтесь поиском по сайту:



©2015 - 2024 megalektsii.ru Все авторские права принадлежат авторам лекционных материалов. Обратная связь с нами...