Синхронизация.

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

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

Коммуникационные примитивы могут быть оформлены в ОС двумя способами:

1. Внутренняя процедура ядра ОС используется только в модулях ОС.

2. Системные вызовы. К ним доступ процессов в пользовательском режиме.

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

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

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

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

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

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

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

Если в ОС имеется один из двух примитивов и ОС гибкая, то поддерживаются как блокирующие, так и не блокирующие.

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

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

2. Когда процесс отправитель посылает сообщение в сеть, не дожидаясь прихода от получателя подтверждения готовности к приёму. После этого процесс отправитель блокируется либо до прихода такого подтверждения, либо до истечения timeout, после которого сообщение посылается вновь. В случае многократных неудачных попыток сообщение отбрасывается.

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

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

Для адресации процесса применяется числовой идентификатор – local_id, который имеет уникальное в пределах узла – это machine_id, значение. Данный идентификатор может однозначно указывать на конкретный процесс, работающий на данном компьютере, то есть является идентификатором процесс_id. Существует другой подход – использование адреса службы, в который пересылается сообщение, когда идентификатор принимает вид service_id. Это удобно для отправителя, так как службы, поддерживаемые сетевыми ОС, представляют широкий набор протоколов (FTP, SMTP, HTTP, SMNP). Эти службам можно присвоить определённые адреса, заранее известные всем отправителям (хорошо известные адреса – well-known address), например номера портов протоколов TCP/FDP. Посылают с помощью этих протоколов на порт 21 службе FTP, т.е. службе передачи файлов. При этом отправителя не интересует, какой именно процесс реализуется в настоящий момент времени услуги FTP на данном компьютере.

Так как применяется стек TCP/IP, то номера портов являются наиболее популярными адресами служб с системах обмена сообщениями сетевыми ОС. Для каждого порта ОС поддерживает буфер системной памяти, куда помещаются отправляемые-получаемые сообщения, адресуемые этому порту. Порт задаётся двухбайтным адресам. Хорошо известным портам отводится диапозон от 1 до 1023. Существуют динамически используемые порты со старшими номерами. Значения портов не закреплены за определёнными службами, поэтому они дополняют хорошо известные порты для обмена в рамках обслуживания некоторой служюбы сообщений. Например, клиент FTP всегда начинается взаимодействовать с сервером FTP отправкой сообщения на порт 21, а после установления сеанса обмена выполняется уже по тому порту, номер которого динамически выбирается в процессе установления сеанса. Данная схема адерсации называется машина-процесс (машина-служба). Основной недостаток – она не гибка и не прозрачна, так как пользователь должен явно указывать адрес машины получателя, и если машина отказывает, то невозможно использовать аналогичную службу, установленную другой. Основной способ повышения степени прозрачности адресации – это использование символьных имён вместо числовых, где адрес состоит из символьного имени узла и символьного имени службы. Пример: FTP:\\fio.local означает, что сообщение направлено службе FTP, работающей на компьютере fio.local.

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

1. Широковещательная – удобно, применяется в ЛВС, в которых все сетевые технологии нижнего уровня поддерживают широковещательные адреса в пределах всей сети. Всё, что выше транспортного в ОСИ – высокоуровневый, всё что ниже – низкоуровневый. Пропусканя способность каналов связи достаточна для обслуживания таких запросов. На широковещание построены все службы ОС (net var), которые являются эталоном прозрачности для пользователя. В данной схеме сервер периодически широковещательно рассылает по сети сообщения о соответствие числовых адресов имени и именам служб. Клиент делает широковещательный запрос о наличие в сети сервера, которая поддерживает определённую службу. Если такой сервер в сети есть, то он отвечает на запрос своим числовым адресом. После обмена подобными сообщениями явно указывает в своём запросе имя сервера, к ресурсам которого он обращается, а клиентская ОС заменяет это имя на числовой адрес в соответствие с информацией широковещательной, распространённый серверов. Данный механизм плохо работает в территориальных сетях, т.к. наличие большого числа клиентов и серверов, а также использование менее скоростных каналов делают широковещательный трафик слишком интенсивным, что не оставляет пропускной способности для передачи пользовательских данных.

2. Специализированные серверы, централизованная служба имён, например DNS. Данная служба считается наиболее перспективным средством повышения прозрачности для пользователей сети. В таких службах можно использовать не просто имена, а имена томов, не указывая точное расположение никакого-либо устройства и при перемещение тома с одного компьютера на другой изменения связи тома с компьютером регистрируются в базе службы Network Directly Service (NDS), поэтому все обращения после перемещения разрешаются корректно после замещения адреса устройства.

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

1. Независимость от нижележащих сетевых протоколов и технологий, для чего используется полнятие коммуникационный домен. Данный домен обладает набором коммуникационных свойств, определяющих способ именования сетевых узлов, ресурсов, характеристики сетевых соединений. Основной (популярный) FTSP/IP.

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

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

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

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

2. Связывание сокета с адресом binet(). Данный вызов связывает либо с высокоуровневым, либо с низкоуровневым адресом. Адрес относится к тому узлу, на котором расположен сокет. Для низкоуровневого адреса адресом является пара ip-port. Параметр длина адреса adrlen позволяет задавать адреса различных типов, в том числе и символьный. Адрес связывается с сокетом тогда, когда связывается с сокетом. Запрос на установление соединения с удалённым сокетом используется только тогда, когда предполагается передавать сообщения в потоково режиме, которые требуют установления соединения. Процедура не симметрична. Данный системный вызов – это запрос клиента на установления соединения с сервером. Аргументы указывают адрес сокета-сервера, с которым устанавливается соединение, а после установления могут передаваться в дуплексном режиме.

3. Ожидания запроса на установление соединения – listen. Данный вызов используется для ожидания запросов. Система обмена сообщениями после отработки данного системного вызова будет принимать запросы на установление, которые имеют адрес сокета и передают их на обработку другому системному вызову (accept), который решает принять или отвергнуть. Аргумент устанавливает максимальное число хранимых системой запросов на установление соединения, ожидающих принятия.

4. Принятие запроса на установление соединения (accept) используется сервером для приёма поступившего от системного вызова listen через определённый сокет от клиента с таким-то адресом (второй аргумент). Если адрес опущен, то принимается запрос от любого клиента, при этом создаётся новый сокет s_new, через который и устанавливается соединение с данным клиентом. Таким образом сокет s используется серверов для приёма запросов на установления соединения от клиентов, а s_new для обмена сообщениями с клиентами по индивидуальным соединениям.

5. Отправка сообщений по установленному соединению write. Сообщение определённой длиной, хранящиеся в буфере с определённым именем, с которым предварительно соединён сокет и приём сообщений по установленному соединению. Сообщение с сокетом с s_new принимается в буфер с определённым размером. Если сообщений нет, то процесс получатель блокируется.

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

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