Контакт:
  • Наши кнопки

  • Карта сайта
  • Вход для админа:

Проблема синхронизации

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

Рис.

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

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

Рассмотрим прежде всего вопрос о распределении серверной и клиентской частей между машинами. В некоторых системах (например, NFS) нет различия между клиентом и сервером, на всех машинах работает то самое базовое программное обеспечение, так что любая машина, которая хочет предложить файловый сервис, свободно может это сделать. Для этого ей достаточно экспортировать имена избранных каталогов, чтобы другие машины могли иметь к ним доступ.

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

Объектно-ориентированный подход к построения операционных систем, который предоставляет порядок процесса добавления модульных расширений к небольшому ядру был принят на вооружение многими известными фирмами, такими как Microsoft, Apple, IBM, Novell/USL (UNIX Systems Laboratories) и Sun Microsystems - все они развернули свои операционные системы в этом направлении. Taligent, общее предприятие IBM и Apple, надеется опередить всех из своей с начала до конца объектно-ориентированной операционной системой.

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

Некоторый прогресс в создании цифровых вычислительных машин состоялся после второй мировой войны.

Понятие виртуальной памяти

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

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

В многозадачной (многопроцессной) системе процесс может находиться в одном из трех основных состояний:

ВЫПОЛНЕНИЕ - активное стостояние процесса, во время которого процесс имеет все необходимые ресурсы и непосредственно выполняется процессором;

ОЖИДАНИЕ - пассивное состояние процесса, процесс заблокирован, он не может выполняться по своим внутренним причинам, он ждет осуществления некоторого события, например, завершения операции внедрения-висновка, получение сообщения от другого процесса, освобождение какого-то необходимого ему ресурса;

ГОТОВНОСТЬ - также пассивное состояние процесса, но в этом случае процесс заблокирован в связи с внешними относительно него обстоятельствами: процесс имеет все необходимые для него ресурсы, он готов выполняться, однако процессор занят выполнениям другого процесса.

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

Примитивы, которые были описаны, есть небуферизуемыми примитивами. Это означает, что вызов ПОЛУЧИТЬ сообщает ядру машины, на которой он выполняется, адрес буфера, в который следует поместить сообщение, которые находится для него.

Эта схема работает прекрасно при условии, что получатель выполняет вызов ПОЛУЧИТЬ раньше, чем отправитель выполняет вызов ПОСЛАТЬ. Вызов ПОЛУЧИТЬ сообщает ядру машины, на которой выполняется, по какому адресу должно поступить ожидаемое сообщение, и в какую область памяти необходимо его поместить.

Файлы идентифицируются именами. Пользователи дают файлам символьные имена, при этом учитываются ограничения ОС как на используемые символы, так и на длину имени. До недавнего времени эти границы были очень узкими. Так в популярной файловой системе FAT длина имен ограничивается известной схемой 8.3 (8 символов - собственное имя, 3 символа - расширение имени), а в ОС UNIX System V имя не может содержать более 14 символов. Однако пользователю намного удобнее работать с длинными именами, поскольку они позволяют даты файла действительно мнемоническое название, по которому даже через достаточно большой промежуток времени можно будет припомнить, что содержит этот файл.

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

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

Прерывания должны быть скрыты как можно глубже в недрах операционной системы, чтобы как можно меньшая часть ОС имела с ними дело. Наилучшее средство составляется в разрешении процесса, который инициировал операцию ввода вывода, блокировать себя к завершению операции и наступление прерывания. Процесс может блокировать себя, используя, например, вызов DOWN для семафора, или вызов WAIT для переменной условия, или вызов RECEIVE для ожидания сообщения. При наступлении прерывания процедура обработки прерывания выполняет разблокирование процесса, который инициировал операцию ввода вывода, используя вызовы UP, SIGNAL или посылая процесса сообщения.

В реальных системах возможность попадания в кэш составляет приблизительно 0,9. Высокое значение возможности пребывания данных в кэш-памяти связано с наличием в данных объективных свойств: пространственной и временной локальности.

Пространственная локальность. Если состоялось обращение по некоторому адресу, то с высокой степенью возможности в ближайшее время  состоится обращения к соседним адресам.

Временная локальность. Если состоялось обращение по некоторому адресу, то такое обращение по этому же адресу с широкой озможность состоится в ближайшее время.

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

В идеале RPC должен функционировать правильно и в случае отказов. Рассмотрим такие классы отказов:

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

Утерян запрос от клиента до серверу. Самое простое решение - через определенное время повторить запрос.


s#0