Что такое синхронизация процессов

Синхронизация процессов и потоков

Процессом (process) называется экземпляр программы, загруженной в память. Этот экземпляр может создавать нити (thread), которые представляют собой последовательность инструкций на выполнение. Важно понимать, что выполняются не процессы, а именно нити.

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

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

Синхронизация нитей в ОС Windows

Пример. Несинхронизированная работа нитей: если временно приостановить выполнение нити вывода на экран (пауза), фоновая нить заполнения массива будет продолжать работать.

Именно поэтому необходим механизм, позволяющий потокам согласовывать свою работу с общими ресурсами. Этот механизм получил название механизма синхронизации нитей (thread synchronization).

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

Работа с объектами синхронизации

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

Критические секции

Объект-критическая секция помогает программисту выделить участок кода, где нить получает доступ к разделяемому ресурсу, и предотвратить одновременное использование ресурса. Перед использованием ресурса нить входит в критическую секцию (вызывает функцию EnterCriticalSection). Если после этого какая-либо другая нить попытается войти в ту же самую критическую секцию, ее выполнение приостановится, пока первая нить не покинет секцию с помощью вызова LeaveCriticalSection. Используется только для нитей одного процесса. Порядок входа в критическую секцию не определен.

Существует также функция TryEnterCriticalSection, которая проверяет, занята ли критическая секция в данный момент. С ее помощью нить в процессе ожидания доступа к ресурсу может не блокироваться, а выполнять какие-то полезные действия.

Пример. Синхронизация нитей с помощью критических секций.

Взаимоисключения

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

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

Для синхронизации нитей одного процесса более эффективно использование критических секций.

Пример. Синхронизация нитей с помощью мьютексов.

События

Пример. Синхронизация нитей с помощью событий.

Семафоры

Пример. Синхронизация нитей с помощью семафоров.

Защищенный доступ к переменным

Существует ряд функций, позволяющих работать с глобальными переменными из всех нитей, не заботясь о синхронизации, т.к. эти функции сами за ней следят – их выполнение атомарно. Это функции InterlockedIncrement, InterlockedDecrement, InterlockedExchange, InterlockedExchangeAdd и InterlockedCompareExchange. Например, функция InterlockedIncrement атомарно увеличивает значение 32-битной переменной на единицу, что удобно использовать для различных счетчиков.

Для получения полной информации о назначении, использовании и синтаксисе всех функций WIN32 API необходимо воспользоваться системой помощи MS SDK, входящей в состав сред программирования Borland Delphi или CBuilder, а также MSDN, поставляемым в составе системы программирования Visual C.

Источник

Национальная библиотека им. Н. Э. Баумана
Bauman National Library

Персональные инструменты

Синхронизация процессов

Синхронизация процессов (от древне-греч. σύγχρονος — одновременный) — приведение двух или нескольких процессов к такому их протеканию, когда определённые стадии разных процессов совершаются в определённом порядке, либо одновременно.

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

Содержание

Необходимость в синхронизации

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

Трудности

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

Некоторые другме трудности, которые предстоит решить при синхронизации процессов:

Порядок совершения действий

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

Взаимная блокировка

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

Существуют алгоритмы удаления взаимной блокировки. В то же время, выполнение алгоритмов поиска удаления взаимных блокировок может привести к livelock — взаимная блокировка образуется, сбрасывается, снова образуется, снова сбрасывается и так далее.

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

Ресурсный голод

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

Инверсия приоритетов

Менее приоритетное задание блокирует совместные ресурсы необходимые более приоритетной задаче. Это приводит к блокировке более приоритетных задач до тех пор, пока задача с более низким приоритетом не разблокирует ресурсы, происходик как бы инверсия относительных приоритетов этих двух задач. Если же в это время попытается исполниться другая средне приоритетная задача, не зависаящая от общего ресурса, то она получит преимущество и над менее и над более приоритетными задачами. Способы решения:

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

Нагруженное ожидание

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

Классические проблемы синхронизации

Некоторые классические проблемы синхронизации:

Задача поставщика-потребителя

Задача может быть обобщена на случай многих поставщиков и потребителей.

Задача о читателях-писателях

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

Первая задача о читателях-писателях (приоритет читателя)

Вторая задача о читателях-писателях (приоритет писателя)

Третья задача о читателях-писателях (честное распределение ресурсов)

Задача обедающих философов

Задача обедающих философов (англ. Dining philosophers problem) — классический пример, используемый в информатике для иллюстрации проблем синхронизации при разработке параллельных алгоритмов и техник решения этих проблем. Сформулирована в 1965 году Эдсгером Дейкстрой как экзаменационное упражнение для студентов. В качестве примера был взят конкурирующий доступ к ленточному накопителю. Вскоре проблема была сформулирована Ричардом Хоаром в том виде, в каком она известна сегодня.

Постановка задачи

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

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

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

Аппаратная синхронизация

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

Источник

Русские Блоги

Управление процессами Синхронизация двух процессов и семафор

Синхронизация процессов: относится к координации нескольких связанных процессов в порядке выполнения;

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

Логическое взаимное ограничение между процессами в системе:

Косвенные отношения-взаимное исключение

Основные концепции синхронизации процессов

1. Две формы ограничения между процессами

Между процессами в системе существует два логически ограничивающих отношения:

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

2. Критические ресурсы, критические области

Пример: проблема производитель-потребитель

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

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

Операция сложения 1 и вычитания 1 для реализации переменных на машинном языке:

Если вы измените переменные в другом порядке, каков будет результат?

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

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

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

Остальной код в процессе, кроме области входа, критической области и области выхода.

Несколько процессов для входа в критическую секцию должны соответствовать:

(1) Только одному процессу разрешено входить в критическую секцию одновременно.

(2) В любой момент в критической зоне не должно быть более одного процесса.

(3) Процесс, который входит в критическую секцию, должен завершиться в течение ограниченного времени.

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

Несколько методов решения проблемы критического участка (взаимного исключения):

(1) Программный метод и аппаратный метод

(3) Механизм управления

3. Правила, которым должен следовать механизм синхронизации.

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

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

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

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

Семафорный механизм

1. Целочисленный семафор

wait(S) : Пока S signal(S) : S = S + 1;

Главная проблема: Пока S Сдавайся и жди ”。

2. Записанный семафор

1. Установите целочисленное значение переменной (семафор ресурса), представляющее количество ресурсов.

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

В записанном семафорном механизме:

Начальное значение S.value представляет количество определенных типов ресурсов в системе.

В записанном семафорном механизме

Каждая операция ожидания (S) означает, что процесс запрашивает единицу ресурсов, и количество ресурсов уменьшается на 1. Когда S.value К пониманию ）

Общий набор семафоров ( К пониманию ）

Семафорное приложение

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

Семафор может легко решить проблему критического раздела (процесс взаимного исключения) (см. Следующий рисунок). Установите взаимоисключающую блокировку семафоров для критических ресурсов, начальное значение равно 1, затем описания процессов A, B и C являются взаимоисключающими:

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

Последовательность предложений процесса P1: S1; V (s)

Последовательность предложений процесса P2: P (s); S2

Пример: использование семафоров для описания взаимосвязи предшествующих графов

Источник

Русские Блоги

Основные понятия операционной системы Глава VI_ Синхронизация процессов

Обзор

Будет много проблем с одновременным выполнением программ.Простым примером является проблема производитель-потребитель.

этоОдновременныйПроблема в том, что несколько процессов одновременноДоступ к одним и тем же данным и управление имиА такжеРезультат выполнения связан с конкретным порядком, в котором произошло посещение., НазываетсяСостояние гонкиЧтобы избежать этой проблемы, необходимо убедиться, что только один процесс может управлять переменными в течение определенного периода времени. count

Необходимо избегать этих проблем, поэтому необходимоСинхронизация процессовс участиемКоординация

Проблема критического сечения

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

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

Ответить на вопросы критического раздела

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

Алгоритм Петерсона

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

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

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

Некоторые аргументы могут показать, что решение алгоритма Петерсона является правильным (то есть взаимное исключение удовлетворено, прямое требование выполнено и требование ограниченного ожидания выполнено)

Аппаратная синхронизация

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

Среди них ситуация однопроцессорного и многопроцессорного отличается:

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

Здесь в учебнике упоминается, что два вышеупомянутых метода решают взаимное исключение, но не решают проблему ограниченного ожидания. Я был другим. После ознакомления с другими статьями, кто-то рассказал о своем понимании.Проблема ограниченного ожидания решается, когда есть два процесса, но нет способа решить проблему ограниченного ожидания, когда есть несколько процессов.。
Те, у кого есть другие идеи, могут оставить сообщение в разделе комментариев для обсуждения.

Также есть TestAndSet() Этот алгоритм удовлетворяет трем требованиям задачи критического сечения.

Классическая проблема синхронизации

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

Проблема производитель-потребитель

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

Читатель-писатель проблема

Чтобы избежать такой путаницы, писатели должны иметь монопольный доступ к общей базе данных. Эта проблема называется проблемой читателя-писателя.

У этого вопроса есть два варианта в зависимости от приоритета читателей и писателей:

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

Проблема еды философа

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

Как правило, существуют следующие методы решения обеденной проблемы философов:

После этого есть несколько схем синхронизации.

сигнал

Аппаратные решения (Аппаратная синхронизацияУпоминается в разделе TestAndSet() с участием Swap() ) Слишком сложен для прикладных программистов. Для решения проблемы критического участка его называютСемафорИнструмент синхронизации.

Использование семафоров

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

Семафоры используются во многих случаях, например,Решить проблему взаимного исключения，Решение проблем с приложением ресурсов，Решить проблемы синхронизации

Решить проблему взаимного исключения

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

Решение проблем с приложением ресурсов

Решить проблемы синхронизации

С помощью следующей формы кода вы можете управлять последовательностью выполнения кода двумя процессами (следующий рисунок представлен только в Обработать Законченный S1 Задний, Процесс b Может выполнить S2 ）：

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

Семафорная реализация

Недостатком упомянутого ранее семафора является ожидание занятости. Чтобы преодолеть этот недостаток, вы можете изменить его. wait() с участием signal() Определение состоит в том, что когда процесс ожидает, он не вращается, а блокирует себя, добавляет себя в очередь ожидания семафоров, переключается в состояние ожидания и переходит к планировщику ЦП, чтобы выбрать другой процесс для выполнения.

Тупик и голод

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

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

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

Найди отличия

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

Семафорное решение классических задач

Проблема производитель-потребитель

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

Читатель-писатель проблема

Вот только решение первой проблемы читателя-писателя:

Подробную информацию см. В документе «Концепция операционной системы, седьмое издание-P179».

mutex с участием wrt Инициализируется 1, readcount При инициализации 0 его цель:

Блокировки чтения-записи наиболее полезны в следующих ситуациях:

Философская обеденная проблема

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

Философы также должны быть уверены, что они не умрут с голоду. Решение без тупика не обязательно гарантирует, что голод не будет.

Трубопровод***

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

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

Работа PV: P означает пройден, V означает выпуск. То есть wait() с участием signal()

использовать

ВидыИнкапсулирует частные данные и общедоступные методы для управления данными, иТрубкаТип

В представление типа трубки входят:

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

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

Очередь ожидания у входа в тубус

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

Очередь ожидания ресурса и переменные условия

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

condition содержать wait() с участием signal() метод x.wait() Означает, что процесс, вызывающий операцию, зависнет, пока другой процесс не вызовет x.signal()

Нет вызова x.wait() В случае звонка x.signal() Никакого эффекта, это разница между условной структурой и семафором

Очередь экстренного ожидания

Допустим, есть приостановленный процесс Q С условными переменными x Связано, теперь при выполнении процесса P Называется x.signal() Когда процесс Q Будет разрешено повторно выполнить, затем концептуально Q с участием P Может продолжать выполняться в процессе управления, поскольку в любой момент в процессе управления может быть только один активный процесс. Поэтому с этим нужно бороться:

Компромиссное решение также предусматривает: signal() Операция должна быть последней исполняемой операцией в процессе (эта схема принята в языке Pascak)

Управленческие решения классических проблем

Философская обеденная проблема

Этот планНет тупикаРешение требует, чтобы философ брал палочки для еды только тогда, когда обе палочки доступны.

Конкретный код и пояснения следующие:

Эта схема гарантирует отсутствие тупика, но не гарантирует, что философы не умрут от голода.

Механизм синхронизации

Атомарная транзакция

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

Системная модель

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

С точки зрения пользователя транзакция представляет собой серию операций чтения и записи, и, наконец, commit или abort Конец

commit Указывает, что транзакция была успешно выполнена
abort Указывает, что транзакция должна прекратить выполнение из-за различных логических ошибок.

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

В этом разделе рассматривается только атомарность транзакций в энергозависимом хранилище.

Восстановление на основе журнала

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

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

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

Перед началом казни Записывается в журнал, в каждом Ti Соответствующие операции должны быть записаны в журнал перед операцией записи и, наконец, после отправки. Записывается в журнал.

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

Алгоритм восстановления состоит из двух шагов:

Все новые и старые значения можно найти в записях журнала.

Если дела Ti Не работает, затем используйте undo(Ti) Восстановить записи. Если система выйдет из строя, вы можете восстановить ее следующим образом:

обращать внимание undo(Ti) с участием redo(Ti) изИдемпотентность, То есть эффект однократного и многократного вызова транзакции Ti Это то же самое.

контрольно-пропускной пункт

Если время записи журнала очень велико, то каждая восстановленная операция извлечения или операция повтора после сбоя системы очень велика.Дополнительные накладные расходы

Чтобы снизить дополнительные расходы, введитеКонтрольно-пропускной пунктИдея, то есть, помимо обновления журнала каждый раз, система должна периодически выполнять контрольные точки и выполнять следующие операции:

Это позволяет системе упростить восстановление. После сбоя системы Все
Объект T Нет необходимости переделывать

Источник