Описать процессы синхронизации в компьютерных сетях

Обновлено: 29.06.2024

Все мы пользуемся Интернетом — разновидностью сети в современных компьютерных системах.

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

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

Современные компьютерные сети используют коммутацию пакетов, так что компьютеры не полагаются на выделенные прямые соединения для связи. Физические соединения между компьютерами являются общими, и сеть передает отдельные пакеты вместо полных соединений. Концепция соединения теперь становится абстракцией, реализуемой уровнями программных протоколов, ответственных за передачу/обработку пакетов, и представляется прикладному программному обеспечению как потоковое соединение операционной системой. Вместо того, чтобы иметь прямое, выделенное подключение к компьютерам по сети, с которой вы хотите общаться, современные компьютерные сети выглядят примерно так, как показано ниже, где большая часть физической инфраструктуры широко используется десятками миллионов других компьютеров, составляющих Интернет: /p>

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

Пакеты

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

Адреса (исходный и конечный)
Контрольная сумма
- для обнаружения повреждения данных во время передачи
- чтобы различать логические соединения с одними и теми же машинами
Сетевые системные вызовы

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

Вспомните, как мы соединяем два процесса с помощью каналов. Существует родительский процесс, который отвечает за все настройки (вызовы pipe(), fork(), dup2(), close() и т. д.) до того, как дочерний процесс запустит новую программу, вызвав execvp(). Здесь такой подход явно не работает, потому что не существует аналога такого «родительского процесса», когда речь идет о совершенно разных компьютерах, пытающихся взаимодействовать друг с другом. Поэтому соединение должно быть установлено с использованием другого процесса с другими абстракциями.

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

Клиентская и серверная стороны используют разные сетевые системные вызовы.

Системный вызов на стороне клиента – подключение
- connect(fd, addr, len) -> int : Установить соединение.
  - fd : дескриптор файла сокета, возвращаемый функцией socket()
  - addr и len : структура C, содержащая информацию об адресе сервера (включая порт) и длину структуры.
  - Возвращает 0 в случае успеха и отрицательное значение в случае неудачи.
  Системные вызовы на стороне сервера
  
  На стороне сервера все немного сложнее. Есть 3 системных вызова:
  - bind(fd, . ) -> int : выбирает порт и связывает его с сокетом fd .
  - listen(fd) -> int : установите состояние сокета fd, чтобы указать, что он может принимать входящие соединения.
  - accept(fd) -> cfd : Ожидание подключения клиента и возврат нового файлового дескриптора сокета cfd после установления нового входящего подключения от клиента. cfd соответствуют активному соединению с клиентом.
  Сервер не готов принимать входящие подключения до тех пор, пока не будет вызван listen() . Это означает, что до того, как сервер вызовет listen(), все входящие запросы на подключение от клиентов будут завершаться ошибкой.
  
  Среди всех этих системных вызовов, упомянутых выше, только connect() и accept() включают фактическую связь по сети, все остальные вызовы просто управляют локальным состоянием. Таким образом, только системные вызовы connect() и accept() могут блокироваться.
  
  Одно интересное различие между каналами и сокетами состоит в том, что каналы являются односторонними, а сокеты — двусторонними: можно читать только с конца канала для чтения и записывать на конец канала для записи, но один могут свободно читать и писать из сокета. В отличие от обычных файловых дескрипторов для файлов, открытых в режиме чтения/записи, запись в сокет отправляет данные в сеть, а чтение из того же сокета будет получать данные из сети. Таким образом, сокеты представляют собой двустороннее соединение между клиентом и сервером, им нужно установить только одно соединение для связи туда и обратно.
  
  Подключения
  
  Соединение – это абстракция, построенная на основе необработанных сетевых пакетов. Это создает иллюзию надежного потока данных между двумя конечными точками соединения. Соединения устанавливаются поэтапно, опять же путем отправки пакетов.
  
  Здесь мы описываем протокол управления передачей (TCP). Существуют и другие сетевые протоколы, которые не используют понятие соединения и напрямую работают с пакетами. Google "протокол дейтаграмм пользователя" или просто "UDP" для получения дополнительной информации.
  
  Соединение устанавливается с помощью так называемого процесса трехстороннего рукопожатия. Клиент инициирует запрос на соединение, используя сетевой пакет, а затем сервер и клиент обмениваются одним раундом пакетов подтверждения, чтобы установить соединение. Этот процесс показан ниже.
  
  ВинсиБД
  
  Теперь мы рассмотрим простую сетевую базу данных WeensyDB, чтобы увидеть, как сеть и синхронизация интегрированы в одну и ту же программу. База данных — это программа, которая хранит данные. В нашем случае приложение WeensyDB имеет серверную и клиентскую стороны. На стороне сервера данные фактически хранятся, и клиент просто запрашивает базу данных по сети и извлекает данные с сервера.
  
  Версия 1: однопоточный сервер
  
  Первая версия серверной базы данных находится в файле synch4/weensydb-01.cc . Мы используем простую хеш-таблицу для представления нашей базы данных. Хэш-таблица состоит из 1024 сегментов, и каждый сегмент представляет собой список элементов для обработки коллизий.
  
  Функция handle_connection() выполняет большую часть логики на стороне сервера при установленном соединении с клиентом. Он читает из сети и анализирует команду, отправленную клиентом. Затем он обрабатывает команду, обращаясь к базе данных (хеш-таблице), а затем записывает результат команды обратно в сетевое соединение, чтобы клиент мог его получить.
  
  Мы можем запустить это приложение базы данных, запустив и сервер, и клиент. Обратите внимание, что простой запуск сервера не генерирует никаких пакетов по сети — это чисто локальная операция, которая просто подготавливает прослушивающий сокет и переводит его в соответствующее состояние. После того, как мы запускаем клиент и вводим команду, мы видим, что пакеты отправляются по сети, в результате устанавливается активное соединение и происходит обмен данными.
  
  В примере, который мы показали в лекции, и клиент, и сервер работали на одном компьютере. Пакеты обменивались через локальный сетевой интерфейс обратной связи, и на самом деле ничего не отправляется по проводу (или WiFi). Для понимания вы можете просто представить, что две программы работают на разных машинах. На самом деле эти две программы не используют для связи ничего, кроме сети, поэтому они очень похожи на то, что работают с разных физических машин.
  
  Сервер базы данных должен обслуживать как можно больше клиентов, при этом один клиент не может мешать подключениям других клиентов. Это похоже на свойства изоляции процесса, предоставляемые ядром ОС. Наша первая версия WeensyDB на самом деле не предоставляет этого свойства. Как мы видим в его реализации -- это однопоточный сервер. Он просто не может обрабатывать два клиентских подключения одновременно, клиенты должны ждать обслуживания один за другим.
  
  Это открывает двери для возможных атак. Злонамеренный клиент, который никогда не закроет свое соединение с сервером, заблокирует работу всех других клиентов. synch4/wdbclientloop.cc содержит клиент с таким плохим поведением, и когда мы используем его с нашей первой версией WeensyDB, мы наблюдаем этот эффект.
  
  Версия 2: Обработка соединения в новом потоке
  
  Следующая версия сервера WeensyDB пытается решить эту проблему с помощью многопоточности. Программа находится в synch4/weensydb-02.cc. Он очень похож на предыдущую версию, за исключением того, что клиентское соединение обрабатывается в новом потоке. Соответствующий код показан ниже:
  
  Этот код больше не блокирует основной поток во время обработки клиентского подключения, поэтому одновременные клиентские подключения могут выполняться параллельно. Здорово! Это действительно работает?
  
  Теперь посмотрим, как мы на самом деле обрабатываем клиентское соединение в функции handle_connection() цикла while:
  
  Мы видим, что при обработке операции набора мы изменяем базовую хеш-таблицу, которая совместно используется всеми потоками, созданными параллельными клиентскими подключениями. И эти модификации вообще не синхронизируются! Действительно, если мы включим дезинфицирующее средство потока, мы увидим много жалоб, указывающих на серьезные условия гонки в нашем коде, когда клиенты параллельно выполняют команды set.
  
  Мы уже проходили через это раньше при работе с ограниченными буферами, поэтому мы знаем, что нам нужно исправить это с помощью мьютекса. Но мы не можем просто защитить весь цикл while, используя блокировку области действия, как мы сделали для ограниченного буфера. Если бы мы это сделали, программа была бы должным образом синхронизирована, но она потеряла бы параллелизм — мьютекс гарантирует, что одновременно может обрабатываться только одно соединение, и мы возвращаемся к однопоточной версии, которая подвержена атакам злоумышленников. клиент.
  
  Ключом к использованию мьютекса в сетевой программе является осознание опасности удержания мьютекса при блокировке сетевых системных вызовов. Блокировка может произойти при отправке/получении данных в сети, поэтому во время сетевой связи мьютекс никогда не должен блокироваться потоком сервера.
  
  Один из способов реорганизовать программу, чтобы избежать этих проблем, — убедиться, что мьютекс блокируется только после того, как от клиента получен полный запрос, и разблокируется перед отправкой ответа. В коде weensydb-02.cc это эквивалентно размещению одной блокировки области действия в каждом блоке if/else if/else в цикле while в handle_connection() .
  
  Версия 3: Детальная блокировка
  
  К этому моменту мы все еще используем грубую блокировку, когда вся хэш-таблица защищена одним мьютексом. В хеш-таблице естественно назначать мьютекс каждой сегменту хэш-таблицы для достижения точной блокировки, поскольку разные сегменты хэш-таблицы гарантированно содержат разные ключи. Эта версия реализована в synch4/weensydb-05.cc.
  
  Версия 4: Обмен
  
  Теперь предположим, что мы должны добавить в базу данных новую функцию: команду обмена, которая меняет местами значения двух ключей. Мы по-прежнему следуем предыдущему мелкозернистому дизайну блокировки, но на этот раз нам нужно будет заблокировать до 2 сегментов для каждой операции. Когда мы блокируем несколько мьютексов в программе, мы всегда должны опасаться возможности взаимоблокировок. В следующий раз у нас будет больше обсуждений взаимоблокировок!
  
  В этом руководстве мы рассмотрим концепцию синхронизации процессов в операционной системе.
  
  Синхронизация процессов была введена для решения проблем, возникающих при выполнении нескольких процессов.
  
  Процессы подразделяются на два типа на основе синхронизации, и они приведены ниже:
  
  Независимые процессы
  
  Два процесса называются независимыми, если выполнение одного процесса не влияет на выполнение другого процесса.
  
  Совместные процессы
  
  Два процесса называются взаимодействующими, если выполнение одного процесса влияет на выполнение другого процесса. Эти процессы необходимо синхронизировать, чтобы можно было гарантировать порядок выполнения.
  
  Синхронизация процессов
  
  Феномен задачи заключается в координации выполнения процессов таким образом, чтобы никакие два процесса не могли иметь доступ к одним и тем же общим данным и ресурсам.
  
  Это процедура, используемая для сохранения надлежащего порядка выполнения совместных процессов.
  
  Для синхронизации процессов существуют различные механизмы синхронизации.
  
  Синхронизация процессов в основном необходима в многопроцессорной системе, когда несколько процессов выполняются вместе, и несколько процессов одновременно пытаются получить доступ к одному и тому же общему ресурсу или любым данным.
  
  Соревнования
  
  В то время, когда несколько процессов либо выполняют один и тот же код, либо обращаются к одной и той же памяти или любой общей переменной; В этом состоянии существует вероятность того, что вывод или значение общей переменной неверны, поэтому для этой цели все процессы соревнуются, чтобы сказать, что мой вывод правильный. Это состояние широко известно как состояние гонки. Поскольку несколько процессов получают доступ и обрабатывают манипуляции с одними и теми же данными одновременно, из-за чего результат зависит от конкретного порядка, в котором происходит доступ к данным.
  
  В основном это ситуация, которая может возникнуть внутри критической секции. Состояние гонки в критической секции возникает, когда результат выполнения нескольких потоков отличается в зависимости от порядка выполнения потоков. Но это условие заключается в том, что критических секций можно избежать, если критическая секция рассматривается как атомарная инструкция. Правильная синхронизация потоков с помощью блокировок или атомарных переменных также может предотвратить состояние гонки.
  
  Проблема критического раздела
  
  Критическая секция — это сегмент кода, который обращается к общим переменным и должен выполняться как атомарное действие. Это означает, что в группе взаимодействующих процессов в данный момент времени только один процесс должен выполнять свой критический участок. Если какой-либо другой процесс также хочет выполнить свою критическую секцию, он должен дождаться завершения первого. Вход в критическую секцию в основном обрабатывается функцией wait(), а выход из критической секции контролируется функцией signal().
  
  Раздел ввода
  
  В этом разделе в основном процесс запрашивает запись в критическую секцию.
  
  Выйти из раздела
  
  За этим разделом следует критический раздел.
  
  Решение проблемы критического раздела
  
  Решение проблемы критического сечения должно удовлетворять следующим трем условиям:
  
  1. Взаимное исключение
  
  Из группы взаимодействующих процессов только один процесс может находиться в своей критической секции в данный момент времени.
  
  2. Прогресс
  
  Если ни один процесс не находится в его критической секции, и если один или несколько потоков хотят выполнить свою критическую секцию, то любой из этих потоков должен быть разрешен для доступа в свою критическую секцию.
  
  3. Ограниченное ожидание
  
  После того как процесс делает запрос на доступ к своей критической секции, существует ограничение на количество других процессов, которые могут получить доступ к своей критической секции, прежде чем запрос этого процесса будет удовлетворен. Таким образом, после достижения предела система должна предоставить процессу разрешение на доступ к его критической секции.
  
  Решения для критической секции
  
  Критическая секция играет важную роль в синхронизации процессов, поэтому проблема должна быть решена.
  
  Некоторыми широко используемыми методами решения проблемы критической секции являются следующие:
  
  1.Решение Петерсона
  
  Это широко используемое программное решение проблем критических секций. Решение Петерсона было разработано ученым-компьютерщиком Петерсоном, поэтому оно и названо так.
  
  С помощью этого решения всякий раз, когда процесс выполняется в каком-либо критическом состоянии, другой процесс выполняет только остальную часть кода, и наоборот. Этот метод также помогает убедиться в том, что только один процесс может работать в критической секции в определенное время.
  
  Это решение сохраняет все три условия:
  
  Взаимное исключение удобно тем, что в любой момент только один процесс может получить доступ к критической секции.
  
  Прогресс также утешается, так как процесс, находящийся за пределами критической секции, не может блокировать вход других процессов в критическую секцию.
  
  Ограниченное ожидание гарантировано, так как каждый процесс имеет равные шансы попасть в критическую секцию.
  
  < /p>
  Выше показана структура процесса Pi в решении Петерсона.
  
  Предположим, что есть N процессов (P1, P2, .PN), и в какой-то момент времени каждый процесс должен войти в критическую секцию
  
  Здесь поддерживается массив FLAG[] размера N, который по умолчанию равен false. Всякий раз, когда процессу требуется войти в критическую секцию, он должен установить свой флаг как истинный. Пример: если Pi хочет войти, он установит FLAG[i]=TRUE.
  
  Другая переменная называется TURN и используется для указания номера процесса, который в данный момент ожидает входа в критическую секцию.
  
  Процесс, который входит в критическую секцию при выходе, изменит TURN на другой номер из списка готовых процессов.
  
  Пример: если ход равен 3, то P3 входит в критическую секцию, а при выходе из поворота = 4, и, следовательно, P4 выходит из цикла ожидания.
  
  Оборудование для синхронизации
  
  Многие системы обеспечивают аппаратную поддержку кода критической секции. Проблема критической секции могла бы быть легко решена в однопроцессорной среде, если бы мы могли запретить возникновение прерываний во время изменения общей переменной или ресурса.
  
  Таким образом, мы могли быть уверены, что текущая последовательность инструкций будет разрешена для выполнения по порядку без приоритета. К сожалению, это решение невозможно в многопроцессорной среде.
  
  Отключение прерывания в многопроцессорной среде может занять много времени, поскольку сообщение передается всем процессорам.
  
  Эта задержка передачи сообщения задерживает вход потоков в критическую секцию, и эффективность системы снижается.
  
  Мьютексы
  
  Поскольку аппаратное решение для синхронизации не всем легко реализовать, был введен строгий программный подход под названием Mutex Locks. При таком подходе во входной части кода БЛОКИРОВКА устанавливается на критические ресурсы, измененные и используемые внутри критической секции, а в выходной части блокировка снимается.
  
  Поскольку ресурс заблокирован, пока процесс выполняет свою критическую секцию, никакой другой процесс не может получить к нему доступ.
  
  Проблема синхронизации процессов возникает в случае кооперативного процесса также из-за того, что ресурсы совместно используются в кооперативных процессах.
  
  Состояние гонки
  Когда несколько процессов выполняют один и тот же код или обращаются к одной и той же памяти или любой общей переменной в этом состоянии, существует вероятность того, что выходные данные или значение общей переменной неверны, поэтому для этого все процессы, выполняющие гонку, говорят, что мой вывод правильный, это состояние известно как состояние гонки. Несколько процессов обращаются к одним и тем же данным и обрабатывают их одновременно, тогда результат зависит от конкретного порядка, в котором происходит доступ.
  Состояние гонки — это ситуация, которая может возникнуть внутри критической секции. Это происходит, когда результат выполнения нескольких потоков в критической секции отличается в зависимости от порядка выполнения потоков.
  
  Состояния гонки в критических разделах можно избежать, если критический раздел рассматривать как атомарную инструкцию. Кроме того, правильная синхронизация потоков с помощью блокировок или атомарных переменных может предотвратить состояние гонки.
  
  Проблема критического раздела
  
  Критический раздел – это сегмент кода, к которому одновременно может обращаться только один процесс. Критический раздел содержит общие переменные, которые необходимо синхронизировать для обеспечения согласованности переменных данных.
  
  В разделе ввода процесс запрашивает запись в критическом разделе.
  - Взаимное исключение: если процесс выполняется в своей критической секции, то никакой другой процесс не может выполняться в этой критической секции.
  - Прогресс: если ни один процесс не выполняется в критической секции, а другие процессы ожидают вне критической секции, то только те процессы, которые не выполняются в своей оставшейся секции, могут участвовать в принятии решения о том, какой из них войдет в критическую секцию следующим, и выбор не может быть отложен на неопределенный срок.
  - Ограниченное ожидание. Должна существовать граница количества раз, когда другим процессам разрешается войти в свои критические секции после того, как процесс сделал запрос на вход в свою критическую секцию и до того, как этот запрос будет удовлетворен.
  Peterson’s Solution
  Peterson’s Solution — это классическое программное решение проблемы критической секции.
  - boolean flag[i]: Инициализируется значением FALSE, изначально никто не заинтересован во входе в критическую секцию
  - int turn : Процесс, чья очередь войти в критическую секцию.
  - Взаимное исключение гарантируется, поскольку только один процесс может получить доступ к критической секции в любой момент времени.
  - Прогресс также гарантирован, так как процесс вне критической секции не блокирует вход других процессов в критическую секцию.
  - Ограниченное ожидание сохраняется, поскольку каждый процесс получает равные шансы.
  - Ожидание занято
  - Не более 2 процессов.
  TestAndSet
  TestAndSet — это аппаратное решение проблемы синхронизации. В TestAndSet у нас есть общая переменная блокировки, которая может принимать одно из двух значений: 0 или 1.
  
  Перед входом в критическую секцию процесс запрашивает блокировку. Если он заблокирован, он продолжает ждать, пока не освободится, а если он не заблокирован, он берет блокировку и выполняет критическую секцию.
  
  В TestAndSet взаимное исключение и ход выполнения сохраняются, но ограниченное ожидание не может быть сохранено.
  
  Вопрос: функции enter_CS() и leave_CS() для реализации критической секции процесса реализованы с использованием инструкции test-and-set следующим образом:
  
  В приведенном выше решении X — это ячейка памяти, связанная с CS, и она инициализирована до 0. Теперь рассмотрим следующие утверждения:
  I. Приведенное выше решение проблемы CS не имеет взаимоблокировок
  II. Решение не требует голодания.
  III. Процессы входят в CS в порядке FIFO.
  IV.Одновременно в CS может войти более одного процесса.
  
  Какое из приведенных выше утверждений ВЕРНО?
  (A) I
  (B) II и III
  (C) II и IV
  (D) IV
  
  Семафор — это сигнальный механизм, и поток, ожидающий семафора, может получить сигнал от другого потока. Это отличается от мьютекса, так как мьютекс может сигнализироваться только потоком, вызвавшим функцию ожидания.
  - Двоичные семафоры: они могут принимать значения только 0 или 1. Они также известны как мьютексы, так как блокировки могут обеспечивать взаимное исключение. Все процессы могут совместно использовать один и тот же семафор мьютекса, который инициализирован равным 1. Затем процесс должен ждать, пока блокировка не станет равной 0. Затем процесс может сделать семафор мьютекса равным 1 и запустить его критическую секцию. Когда он завершает свою критическую секцию, он может сбросить значение семафора мьютекса на 0, и какой-либо другой процесс может войти в его критическую секцию.
  - Подсчет семафоров. Они могут иметь любое значение и не ограничены определенным доменом. Их можно использовать для управления доступом к ресурсу, имеющему ограничение на количество одновременных обращений. Семафор может быть инициализирован числом экземпляров ресурса. Всякий раз, когда процесс хочет использовать этот ресурс, он проверяет, больше ли количество оставшихся экземпляров нуля, т. е. есть ли у процесса доступный экземпляр. Затем процесс может войти в свою критическую секцию, тем самым уменьшив значение счетного семафора на 1. После завершения процесса с использованием экземпляра ресурса он может покинуть критическую секцию, тем самым прибавив 1 к числу доступных экземпляров ресурса.
  Пожалуйста, напишите комментарии, если обнаружите что-то неверное или хотите поделиться дополнительной информацией по теме, обсуждавшейся выше
  
  Это состояние, когда несколько процессов пытаются одновременно получить доступ к ресурсам и изменить общие данные, а результат процесса зависит от конкретного порядка выполнения, что приводит к несогласованности данных. Это состояние называется состоянием гонки. Это состояние может быть избегали использования метода, называемого синхронизацией или синхронизацией процессов, при котором мы разрешаем только одному процессу входить и манипулировать общими данными в критической секции.
  //диаграмма представления CS
  - Входная секция.
    Это часть процесса, которая определяет вхождение определенного процесса в критическую секцию среди многих других процессов.
  - Критическая секция.
    Это часть, в которой только одному процессу разрешено вводить и изменять общую переменную. Эта часть процесса гарантирует, что только никакой другой процесс не сможет получить доступ к ресурсу общих данных.
  - Секция выхода.
    Этот процесс позволяет другому процессу, ожидающему в секции входа, войти в критические секции. Он проверяет, что процесс, который после завершения выполнения процесса в критической секции, может быть удален через эту секцию выхода.
  - Оставшаяся часть.
    Другие части Кодекса, кроме раздела «Вход», «Критическая часть» и «Выходная часть», называются «Оставшаяся часть».
  1. Взаимное исключение.
    Указывает, что никакой другой процесс не может выполняться в критической секции, если процесс выполняется в критической секции.
  2. Ход выполнения.
    Если ни один процесс не находится в критической секции, то любой процесс вне этого запроса на выполнение может войти в критическую секцию без каких-либо задержек. Только те процессы могут войти в процесс, которые запросили и имеют конечное время для входа в процесс.
  3. Ограниченное ожидание.
    Должна существовать верхняя граница количества входов процесса, чтобы другие процессы могли войти в свои критические секции после того, как процесс сделал запрос на вход в свою критическую секцию и до этого запроса. предоставляется.
  Другой программный подход, известный как решение Петерсона, лучше всего подходит для синхронизации. Он использует две переменные в разделе ввода, чтобы поддерживать согласованность, например, флаг (логическая переменная) и переменная поворота (хранение состояний процесса). Он удовлетворяет всем трем требованиям критической секции.
  
  //Изображение алгоритма Петерсона
  
  Использование прерываний.
  Это легко реализовать.Когда прерывание отключено, никакому другому процессу не разрешается выполнять операцию переключения контекста, которая позволила бы только одному процессу войти в критическое состояние.
  
  //Изображение прерываний
  
  Операция Test_and_Set.
  Это позволяет использовать логическое значение (True/False) в качестве аппаратной синхронизации, которая является атомарной по своей природе, т. е. никакому другому прерыванию не разрешен доступ. Это в основном используется в приложении взаимного исключения. Операция аналогичного типа может быть достигнута с помощью функции сравнения и замены. В этом процессе разрешен доступ к переменной в критической секции, пока ее операция блокировки включена. До тех пор другой процесс находится в состоянии ожидания занятости. Следовательно, требования критического раздела выполнены.
  
  Синхронизация времени — это процесс согласования времени независимых часов. В часах и часах часто используются относительно недорогие компоненты, которые не отличаются особой точностью. Многие будут отклоняться на несколько секунд каждый день.
  
  Даже часы, настроенные на одинаковое время, через относительно короткий промежуток времени будут значительно различаться. В современных вычислениях дрейф часов может быть серьезной проблемой.
  - Процесс согласования часов компьютеров жизненно важен.
  - Без синхронизации часы будут расходиться.
  - Современные распределенные компьютерные системы полагаются на синхронизацию часов.
  - Системы GPS и GNSS являются важным источником точного времени.
  - Такие протоколы, как NTP и PTP, синхронизируют сети компьютеров.
  Синхронизация системных часов компьютера
  
  Синхронизация времени компьютера — это процесс обеспечения согласованности системных часов компьютеров. Компьютерные часы реального времени так же подвержены дрейфу, как и любые другие часы.
  
  Однако протоколы были разработаны специально для обеспечения координации времени сетевых компьютеров. Протокол сетевого времени (NTP) и протокол точного времени (PTP) предназначены для координации системного времени.
  
  Протоколы распределяют метки времени между одним или несколькими главными часами и клиентами времени.
  
  Внешняя синхронизация времени компьютеров
  
  Синхронизацию времени компьютерных систем часто называют «внешней» или «внутренней». Внешняя синхронизация времени — это термин, используемый для описания системы, которая использует систему отсчета времени, например GPS или радио, для предоставления точного времени.
  
  Внутренняя синхронизация времени означает, что компьютеры синхронизируются друг с другом, но только между собой и не обязательно точно.
  
  Важность скоординированных сетевых часов
  
  В современных распределенных компьютерных приложениях синхронизация системного времени между компьютерами часто имеет решающее значение. Время — это единственная доступная ссылка, которую можно использовать для определения порядка процессов или последовательности событий.
  
  Действительно, для многих приложений точная синхронизация компьютерных систем является требованием закона.
  
  Среда управления требует, чтобы задачи, выполняемые независимыми устройствами, выполнялись упорядоченным образом. Без синхронизации это было бы невозможно. Точно так же регистрация событий или обработка транзакций могут выполняться только с согласованным временем, чтобы точно определить, когда произошли события.
  
  Во многих юрисдикциях законодательство о финансовой торговле, например MiFID II, требует синхронизации всех рабочих часов, которые используются для регистрации времени событий. В законодательстве также могут быть указаны нормативные технические стандарты уровня точности часов.
  
  Чтобы быть допущенными к рассмотрению в суде, сетевые камеры видеонаблюдения и записывающее оборудование могут быть согласованы с юридически отслеживаемым источником времени. Это делается для того, чтобы бесспорно доказать время, когда события или преступления действительно имели место.
  
  Протокол сетевого времени (NTP)
  
  Протокол сетевого времени (NTP) был разработан для координации времени в Интернете и на сетевых компьютерах. Это один из старейших интернет-протоколов, который используется до сих пор.
  
  NTP реализует иерархическую систему отсчета времени. Уровень иерархии, называемый стратой, представляет собой расстояние между сервером синхронизации времени и исходными эталонными часами. Чем ниже страта, тем ближе эталонные часы. Устройства уровня 1 подключаются напрямую к аппаратным часам, таким как GPS или источник времени по радио.
  
  Из-за задержки сетевых пакетов каждый уровень страты снижает точность, поэтому чем ближе клиент времени к эталонным часам, тем точнее он будет.
  
  В Интернете доступно большое количество бесплатных NTP-серверов. Однако они имеют ряд недостатков. Многие из них настроены неправильно, и на них нельзя всегда положиться.
  
  Нет гарантии обслуживания, они могут быть ненадежными, временно отключенными. Кроме того, задержки и задержки в сети Интернет приводят к неточности синхронизации. Безопасность также может быть проблемой из-за требования оставлять открытым порт в брандмауэре, чтобы разрешить обмен данными по протоколу NTP.
  
  Выделенные серверы Stratum-1 GPS NTP, установленные непосредственно в сети, могут преодолеть все недостатки серверов времени в Интернете. Задержки в сети значительно снижены, а безопасность повышена, поскольку доступ в Интернет не требуется.
  
  Синхронизация времени операционных систем Windows
  
  В Windows есть специальная служба синхронизации времени под названием Windows Time (w32time.exe). Для одноранговых сетей служба управляется из апплета Дата и время.
  
  Служба позволяет часам компьютера синхронизироваться с интернет-сервером или локальным сервером времени NTP. Доменное имя или IP-адрес сервера времени вводится на вкладке Интернет-время апплета.
  
  Однако обновление можно принудительно выполнить, нажав кнопку «Обновить сейчас», которая проверяет доступность выбранного сервера. Более регулярные обновления можно запланировать, изменив раздел реестра:
  
  Вкладка "Параметры Интернет-времени Windows"
  
  Синхронизация времени домена Windows
  
  Домены Windows или активный каталог устанавливают время в иерархическом порядке. Основной контроллер домена (PDC) корневого домена получает время от внешнего NTP-сервера (в Интернете или локально).
  PDC домена получает время от любого контроллера домена родительского домена.
  
  Все контроллеры домена устанавливают свое время с основного контроллера домена. Все компьютеры-участники или рабочие станции получают время от любого контроллера домена.
  
  Как правило, конфигурации службы времени по умолчанию достаточно. Однако утилиту командной строки w32tm.exe можно использовать для изменения или добавления серверов времени в основной контроллер домена.
  
  w32tm /config /manualpeerlist:"timeserverlist" /syncfromflags:manual /reliable:yes /update
  
  где timeserverlist — список NTP-серверов, разделенных пробелами, заключенный в кавычки.
  
  Следующую команду можно запустить на контроллерах домена, чтобы настроить машину на использование иерархии домена (AD) в качестве источника времени.
  
  w32tm /config /syncfromflags:domhier /update
  
  Чтобы любые изменения вступили в силу, необходимо перезапустить службу w32time с помощью:
  
  net stop w32time
  net start w32time
  
  Синхронизация операционных систем Linux и UNIX
  
  Операционные системы Linux и UNIX используют стандартный демон NTP для установки системных часов. В большинстве установок это установлено по умолчанию. Однако исходный код для компиляции можно получить на веб-сайте распространения NTP.
  
  Демон NTP берет свои настройки из файла конфигурации при запуске, расположение по умолчанию — /etc/ntp.conf. Файл состоит из ряда команд конфигурации для управления поведением демона NTP.
  
  Основной файл конфигурации NTP:
  
  В первых строках файла конфигурации указываются серверы, с которыми необходимо установить связь и использовать в алгоритме выбора часов. Адрес сервера может быть либо полным доменным именем, либо IP-адресом.
  
  Рекомендуется указывать нечетное количество серверов. Это позволяет обнаруживать серверы с ошибочным временем или ложными тиккерами и исключать их из алгоритма выбора часов.
  
  Файл дрейфа указывает расположение файла, в котором может храниться ошибка частоты или дрейф системных часов.Файл обновляется каждый час, но для расчета значимого значения требуется не менее 24 часов.
  
  Этот файл используется для инициализации ошибки частоты, используемой демоном NTP при запуске. Для облегчения синхронизации рекомендуется всегда указывать в файле конфигурации дрейф-файл.
  
  Отладка службы синхронизации времени
  
  NTP также включает ряд утилит для запросов и отладки службы. Наиболее полезной является стандартная программа запросов ntp — ntpq.
  
  Командная строка «ntpq -p» может использоваться для отображения состояния и рабочих параметров одноранговых эталонных часов, используемых службой NTP:
  
  Информация о состоянии включает: доменное имя и IP-адрес эталонных часов, как часто они опрашиваются и когда последний раз опрашивались. Также отображается время, затраченное на связь с одноранговым узлом, а также смещение относительно текущего системного времени и качество часов или дрожание.
  
  Обзор
  
  Синхронизация времени и координация времени компьютерных систем и сетей имеют решающее значение. Протокол сетевого времени (NTP) — это один из нескольких протоколов, предназначенных для поддержания точного системного времени. NTP широко доступен во многих операционных системах, включая Windows, Linux и UNIX. Интернет-источники времени предоставляют бесплатный источник точного времени, но имеют ряд недостатков по сравнению с серверами синхронизации времени Stratum 1, привязанными к GPS.
  
  TimeTools — ведущий британский производитель опорных источников времени Stratum 1 GPS и GNSS для сетевых приложений синхронизации.
  
  Читайте также: