[ новости /+++ | форум | теги | ]

Каталог документации / Раздел "Программирование, языки" / Оглавление документа

Введение.

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

Чтобы различные программы могли обмениваться информацией через файлы или общую базу данных, они, как правило, работают через соответствующий API (Application Programming Interface - интерфейс программирования приложения). Если программы находятся на различных компьютерах, то процесс взаимодействия сопряжен с определенными дополнительными трудностями, например, ограниченной пропускной способностью и сложностью синхронизации. Для организации коммуникации между одновременно работающими процессами применяются средства IPC (Interprocess Communication).

Выделяются три уровня IPC: локальные, удаленные и высокоуровневые.

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

Удаленные IPC представляют механизмы, которые обеспечивают взаимодействие как в пределах одного процессора, так и между программами на различных процессорах, соединенных через сеть. Сюда относятся удаленные вызовы процедур (Remote Procedure Calls - RPC), сокеты Unix, а также TLI (Transport Layer Interface - интерфейс транспортного уровня) фирмы Sun.

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

Средства IPC, впервые реализованные в UNIX 4.2BSD, включали в себя многие современные идеи, одновременно пытаясь соответствовать философии UNIX с точки зрения простоты и краткости.

До введения механизмов межпроцессного взаимодействия UNIX не обладал удобными возможностями для обеспечения подобных услуг. Единственным стандартным механизмом, который позволял двум процессам связываться между собой, были трубы (pipes). К сожалению, трубы имели очень серьезное ограничение в том, что два поддерживающих связь процесса должны были быть связаны через общего предка. Кроме того, семантика труб почти не позволяет поддержку распределенной вычислительной среды.

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

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

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

• Синхронный доступ. Если все процессы читают данные из файла, в большинстве случае проблемы не возникают. Однако, если один из процессов хочет изменить этот файл, могут возникнуть так называемые конкурентные ситуации (race conditions). Эту проблему можно устранить с помощью синхронизации процессов.
• Дисциплина доступа. Если нужно, чтобы как можно большее количество пользователей могли записывать данные, организуется так называемая очередь (по правилу один пишет, несколько читают). Практически организуется 2 очереди, одна для чтения, а другая для записи. Такую дисциплину доступа можно также организовать с помощью барьеров. При этом существует общий барьер для считывателей, так как несколько процессов могут читать одновременно, а также отдельный барьер для процесса-писателя. Такая организация предотвращает взаимные помехи в работе.
• Голодание процессов. Организация дисциплины доступа может привести к ситуации, когда процесс вечно ждет своей очереди, чтобы записать данные. Поэтому иногда нужно организовывать очереди с приоритетами.
• Управление потоком. Если нельзя точно определить, какой из процессов запрашивает или возвращает свои данные в нужный компьютер первым, используется так называемое взаимодействие модели клиент-сервер. При этом используется один или несколько клиентов и один сервер. Клиент посылает запрос серверу, а сервер отвечает на него. После этого клиент должен дождаться ответа сервера, чтобы продолжать дальнейшее взаимодействие. Именно это и называется управлением потоком. При одновременном доступе здесь также могут использоваться очереди с приоритетами.
• Дедлок(deadlock). Классический дедлок возникает, если процесс A получает доступ к файлу A и ждет освобождения файла B. Одновременно процесс B получает доступ к файлу B и ждет освобождения файла A. Оба процесса теперь ждут освобождения ресурсов другого процесса и не освобождают при этом собственный файл. Дедлока можно избежать, если ресурсы будут пронумерованы и предоставляться только в восходящем порядке номеров. Кроме того, все ресурсы должны освобождаться немедленно после окончания использования.

Партнёры:

Хостинг: