Введение
Меры по обеспечению корректности результатов параллельных вычислений
В информационных технологиях и компьютерных науках, особенно в областях компьютерного программирования, операционных систем, многопроцессорных систем и баз данных, управление параллелизмом обеспечивает получение корректных результатов при выполнении параллельных операций, при этом стремясь к максимальной скорости их выполнения. Компьютерные системы, как аппаратные, так и программные, состоят из модулей, или компонентов. Каждый компонент разработан для корректной работы, то есть для соблюдения определенных правил согласованности. Когда компоненты, работающие параллельно, взаимодействуют посредством обмена сообщениями или общим доступом к данным (в памяти или хранилище), согласованность одного компонента может быть нарушена другим. Общая область управления параллелизмом предоставляет правила, методы, методологии проектирования и теории для поддержания согласованности компонентов, работающих параллельно и взаимодействующих между собой, и, следовательно, согласованности и корректности всей системы. Внедрение управления параллелизмом в систему означает применение ограничений к операциям, что обычно приводит к некоторому снижению производительности. Достижение согласованности и корректности операций должно осуществляться с максимально возможной эффективностью, без снижения производительности ниже приемлемого уровня. Управление параллелизмом может потребовать значительной дополнительной сложности и накладных расходов в параллельном алгоритме по сравнению с более простым последовательным алгоритмом. Например, ошибка в управлении параллелизмом может привести к повреждению данных из-за неполных операций чтения или записи.
Транзакции с базы данных и правила ACID
Концепция транзакции базы данных (или атомарной транзакции) развилась для обеспечения как понятного поведения системы базы данных в условиях сбоев, которые могут произойти в любой момент времени, так и восстановления базы данных до известного, корректного состояния. Транзакция базы данных — это единица работы, обычно заключающая в себе набор операций над базой данных (например, чтение объекта базы данных, запись, получение блокировки и т. п.), являющаяся абстракцией, поддерживаемой как в базах данных, так и в других системах. Каждая транзакция имеет чётко определённые границы, определяющие, какие выполнения программы/кода включены в эту транзакцию (определяемые программистом транзакции с помощью специальных команд транзакции). Каждая транзакция в базе данных подчиняется следующим правилам (поддерживаемым системой базы данных, то есть система базы данных спроектирована для их гарантии для выполняемых транзакций):
Atomicity Either the effects of all or none of its operations remain ("all or nothing" semantics) when a transaction is completed (committed or aborted respectively). In other words, to the outside world a committed transaction appears (by its effects on the database) to be indivisible (atomic), and an aborted transaction does not affect the database at all. Either all the operations are done or none of them are. Consistency Every transaction must leave the database in a consistent (correct) state, i. e., maintain the predetermined integrity rules of the database (constraints upon and among the database's objects). A transaction must transform a database from one consistent state to another consistent state (however, it is the responsibility of the transaction's programmer to make sure that the transaction itself is correct, i. e., performs correctly what it intends to perform (from the application's point of view) while the predefined integrity rules are enforced by the DBMS). Thus since a database can be normally changed only by transactions, all the database's states are consistent. Isolation Transactions cannot interfere with each other (as an end result of their executions). Moreover, usually (depending on concurrency control method) the effects of an incomplete transaction are not even visible to another transaction. Providing isolation is the main goal of concurrency control. Durability Effects of successful (committed) transactions must persist through crashes (typically by recording the transaction's effects and its commit event in a non volatile memory). The concept of atomic transaction has been extended during the years to what has become Business transactions which actually implement types of Workflow and are not atomic. However also such enhanced transactions typically utilize atomic transactions as components.
Атомарность: либо эффекты всех операций сохраняются, либо ни одна из них не сохраняется ("всё или ничего") после завершения транзакции (подтверждения или отката соответственно). Иными словами, для внешнего мира подтверждённая транзакция выглядит (по своим эффектам на базу данных) как неделимая (атомарная), а отменённая транзакция никак не влияет на базу данных. Либо все операции выполнены, либо ни одна из них.
Atomicity Either the effects of all or none of its operations remain ("all or nothing" semantics) when a transaction is completed (committed or aborted respectively). In other words, to the outside world a committed transaction appears (by its effects on the database) to be indivisible (atomic), and an aborted transaction does not affect the database at all. Either all the operations are done or none of them are. Consistency Every transaction must leave the database in a consistent (correct) state, i. e., maintain the predetermined integrity rules of the database (constraints upon and among the database's objects). A transaction must transform a database from one consistent state to another consistent state (however, it is the responsibility of the transaction's programmer to make sure that the transaction itself is correct, i. e., performs correctly what it intends to perform (from the application's point of view) while the predefined integrity rules are enforced by the DBMS). Thus since a database can be normally changed only by transactions, all the database's states are consistent. Isolation Transactions cannot interfere with each other (as an end result of their executions). Moreover, usually (depending on concurrency control method) the effects of an incomplete transaction are not even visible to another transaction. Providing isolation is the main goal of concurrency control. Durability Effects of successful (committed) transactions must persist through crashes (typically by recording the transaction's effects and its commit event in a non volatile memory). The concept of atomic transaction has been extended during the years to what has become Business transactions which actually implement types of Workflow and are not atomic. However also such enhanced transactions typically utilize atomic transactions as components.
Согласованность: каждая транзакция должна приводить базу данных в согласованное (корректное) состояние, то есть поддерживать предопределённые правила целостности базы данных (ограничения на объекты базы данных и между ними). Транзакция должна преобразовывать базу данных из одного согласованного состояния в другое согласованное состояние (однако ответственность за корректность самой транзакции лежит на её программисте, то есть за то, чтобы она правильно выполняла то, что от неё требуется (с точки зрения приложения), в то время как предопределённые правила целостности обеспечиваются СУБД). Таким образом, поскольку база данных может изменяться только транзакциями, все её состояния являются согласованными.
Atomicity Either the effects of all or none of its operations remain ("all or nothing" semantics) when a transaction is completed (committed or aborted respectively). In other words, to the outside world a committed transaction appears (by its effects on the database) to be indivisible (atomic), and an aborted transaction does not affect the database at all. Either all the operations are done or none of them are. Consistency Every transaction must leave the database in a consistent (correct) state, i. e., maintain the predetermined integrity rules of the database (constraints upon and among the database's objects). A transaction must transform a database from one consistent state to another consistent state (however, it is the responsibility of the transaction's programmer to make sure that the transaction itself is correct, i. e., performs correctly what it intends to perform (from the application's point of view) while the predefined integrity rules are enforced by the DBMS). Thus since a database can be normally changed only by transactions, all the database's states are consistent. Isolation Transactions cannot interfere with each other (as an end result of their executions). Moreover, usually (depending on concurrency control method) the effects of an incomplete transaction are not even visible to another transaction. Providing isolation is the main goal of concurrency control. Durability Effects of successful (committed) transactions must persist through crashes (typically by recording the transaction's effects and its commit event in a non volatile memory). The concept of atomic transaction has been extended during the years to what has become Business transactions which actually implement types of Workflow and are not atomic. However also such enhanced transactions typically utilize atomic transactions as components.
Изоляция: транзакции не должны влиять друг на друга (как конечный результат их выполнения). Более того, как правило (в зависимости от метода управления конкурентным доступом), эффекты незавершённой транзакции даже не видны другим транзакциям. Обеспечение изоляции — основная цель управления конкурентным доступом.
Atomicity Either the effects of all or none of its operations remain ("all or nothing" semantics) when a transaction is completed (committed or aborted respectively). In other words, to the outside world a committed transaction appears (by its effects on the database) to be indivisible (atomic), and an aborted transaction does not affect the database at all. Either all the operations are done or none of them are. Consistency Every transaction must leave the database in a consistent (correct) state, i. e., maintain the predetermined integrity rules of the database (constraints upon and among the database's objects). A transaction must transform a database from one consistent state to another consistent state (however, it is the responsibility of the transaction's programmer to make sure that the transaction itself is correct, i. e., performs correctly what it intends to perform (from the application's point of view) while the predefined integrity rules are enforced by the DBMS). Thus since a database can be normally changed only by transactions, all the database's states are consistent. Isolation Transactions cannot interfere with each other (as an end result of their executions). Moreover, usually (depending on concurrency control method) the effects of an incomplete transaction are not even visible to another transaction. Providing isolation is the main goal of concurrency control. Durability Effects of successful (committed) transactions must persist through crashes (typically by recording the transaction's effects and its commit event in a non volatile memory). The concept of atomic transaction has been extended during the years to what has become Business transactions which actually implement types of Workflow and are not atomic. However also such enhanced transactions typically utilize atomic transactions as components.
Долговечность: эффекты успешно (подтверждённых) транзакций должны сохраняться даже в случае сбоев (обычно путём записи эффектов транзакции и события её подтверждения в энергонезависимую память). Концепция атомарных транзакций со временем была расширена до бизнес-транзакций, которые фактически реализуют типы рабочих процессов и не являются атомарными. Однако и такие расширенные транзакции обычно используют атомарные транзакции в качестве компонентов.
Atomicity Either the effects of all or none of its operations remain ("all or nothing" semantics) when a transaction is completed (committed or aborted respectively). In other words, to the outside world a committed transaction appears (by its effects on the database) to be indivisible (atomic), and an aborted transaction does not affect the database at all. Either all the operations are done or none of them are. Consistency Every transaction must leave the database in a consistent (correct) state, i. e., maintain the predetermined integrity rules of the database (constraints upon and among the database's objects). A transaction must transform a database from one consistent state to another consistent state (however, it is the responsibility of the transaction's programmer to make sure that the transaction itself is correct, i. e., performs correctly what it intends to perform (from the application's point of view) while the predefined integrity rules are enforced by the DBMS). Thus since a database can be normally changed only by transactions, all the database's states are consistent. Isolation Transactions cannot interfere with each other (as an end result of their executions). Moreover, usually (depending on concurrency control method) the effects of an incomplete transaction are not even visible to another transaction. Providing isolation is the main goal of concurrency control. Durability Effects of successful (committed) transactions must persist through crashes (typically by recording the transaction's effects and its commit event in a non volatile memory). The concept of atomic transaction has been extended during the years to what has become Business transactions which actually implement types of Workflow and are not atomic. However also such enhanced transactions typically utilize atomic transactions as components.
Почему необходим контроль сопутствующего действия?
Если транзакции выполняются последовательно, то есть одна за другой без перекрытия во времени, то параллельное выполнение транзакций отсутствует. Однако, если допускается одновременное выполнение транзакций с чередующимися операциями без какого-либо контроля, могут возникнуть неожиданные и нежелательные результаты, такие как:
Проблема потери обновления: вторая транзакция перезаписывает значение элемента данных (атома) значением, записанным первой параллельной транзакцией, в результате чего первое значение теряется для других параллельно выполняющихся транзакций, которым, согласно порядку их выполнения, необходимо было прочитать первое значение. Транзакции, прочитавшие неверное значение, завершаются с некорректными результатами.
Проблема "грязного чтения": транзакции считывают значение, записанное транзакцией, которая впоследствии была отменена. Это значение исчезает из базы данных при отмене и не должно было быть прочитано ни одной транзакцией ("грязное чтение"). Транзакции, выполнившие чтение, завершаются с некорректными результатами.
Проблема неверного суммарного значения: пока одна транзакция вычисляет суммарное значение всех экземпляров повторяющегося элемента данных, вторая транзакция обновляет некоторые из этих экземпляров. В результате вычисленное суммарное значение не соответствует корректному результату ни для какого (обычно необходимого для обеспечения корректности) порядка выполнения двух транзакций (если одна выполняется перед другой), а представляет собой случайный результат, зависящий от времени обновления и от того, были ли результаты определенных обновлений включены в суммарное значение или нет.
Большинству высокопроизводительных транзакционных систем необходимо выполнять транзакции параллельно для достижения требуемой производительности. Таким образом, без контроля параллелизма такие системы не могут обеспечивать корректные результаты и поддерживать целостность своих баз данных.
The lost update problem: A second transaction writes a second value of a data item (datum) on top of a first value written by a first concurrent transaction, and the first value is lost to other transactions running concurrently which need, by their precedence, to read the first value. The transactions that have read the wrong value end with incorrect results. The dirty read problem: Transactions read a value written by a transaction that has been later aborted. This value disappears from the database upon abort, and should not have been read by any transaction ("dirty read"). The reading transactions end with incorrect results. The incorrect summary problem: While one transaction takes a summary over the values of all the instances of a repeated data item, a second transaction updates some instances of that data item. The resulting summary does not reflect a correct result for any (usually needed for correctness) precedence order between the two transactions (if one is executed before the other), but rather some random result, depending on the timing of the updates, and whether certain update results have been included in the summary or not. Most high performance transactional systems need to run transactions concurrently to meet their performance requirements. Thus, without concurrency control such systems can neither provide correct results nor maintain their databases consistently.
Основные цели механизмов контроля конкуренции
Механизмы управления параллелизмом прежде всего должны работать корректно, то есть обеспечивать соблюдение правил целостности каждой транзакции (в контексте параллельного выполнения; правила целостности, специфичные для приложения, здесь не рассматриваются), в процессе одновременного выполнения транзакций, и, следовательно, целостность всей транзакционной системы. Корректность необходимо обеспечивать с максимально возможной производительностью. Кроме того, всё чаще возникает потребность в эффективной работе при распределении транзакций между процессами, компьютерами и компьютерными сетями. Восстановление и репликация – другие аспекты, которые могут влиять на управление параллелизмом.
Сериализируемость
Для обеспечения корректности, общая основная цель большинства механизмов управления параллелизмом – генерация расписаний с свойством сериализуемости. Без сериализуемости могут возникать нежелательные явления, например, деньги могут исчезать со счетов или появляться из ниоткуда. Сериализуемость расписания означает эквивалентность (в результирующих значениях базы данных) некоторому последовательному расписанию с теми же транзакциями (то есть, в котором транзакции выполняются последовательно, без перекрытия во времени и, следовательно, полностью изолированы друг от друга: одновременный доступ любых двух транзакций к одним и тем же данным невозможен). Сериализуемость считается наивысшим уровнем изоляции среди транзакций базы данных и основным критерием корректности для параллельных транзакций. В некоторых случаях допускаются упрощенные, ослабленные формы сериализуемости для повышения производительности (например, популярный механизм изоляции Snapshot) или для удовлетворения требований к доступности в высокораспределенных системах (см. Конечная согласованность), но только если ослабление не нарушает корректность приложения (например, ослабление недопустимо для денежных операций, поскольку в результате ослабления деньги могут исчезнуть или появиться из ниоткуда). Почти все реализованные механизмы управления параллелизмом достигают сериализуемости, обеспечивая сериализуемость по конфликтам – широкую частную форму сериализуемости (то есть, она охватывает и позволяет реализовать большинство сериализуемых расписаний, не налагая при этом значительных дополнительных ограничений, вызывающих задержки), которую можно эффективно реализовать.
Распространение
С быстрым технологическим развитием вычислительной техники различие между локальными и распределенными вычислениями в сетях с низкой задержкой или шинах становится всё менее четким. Поэтому достаточно эффективное использование локальных методов в таких распределенных средах – обычное явление, например, в компьютерных кластерах и многоядерных процессорах. Однако локальные методы имеют свои ограничения и используют многопроцессорность (или многопоточность), поддерживаемую многопроцессорными (или многоядерными) системами, для масштабирования. Это часто приводит к тому, что транзакции становятся распределенными, если им самим необходимо охватывать несколько процессов. В таких случаях большинство локальных механизмов управления конкурентным доступом плохо масштабируются.
Восстановление
Все системы подвержены отказам, и обеспечение восстановления после отказа необходимо. Свойства формируемых расписаний, определяемые механизмом управления параллельным доступом, могут влиять на эффективность и результативность восстановления. Например, свойство строгости (упомянутое в разделе "Восстанавливаемость" выше) часто желательно для эффективного восстановления.
Репликация
Для обеспечения высокой доступности объекты баз данных часто реплицируются. Необходимо поддерживать синхронизацию обновлений реплик одного и того же объекта базы данных. Это может повлиять на способ реализации управления параллельным доступом (например, Gray et al., 1996).
Контроль одновременной работы в операционных системах
Многозадачные операционные системы, особенно операционные системы реального времени, должны поддерживать иллюзию одновременного выполнения всех задач, работающих поверх них, хотя в любой момент времени фактически выполняется только одна или несколько задач из-за ограничений аппаратного обеспечения, на котором работает операционная система. Такая многозадачность относительно проста, когда все задачи независимы друг от друга. Однако, когда несколько задач пытаются использовать один и тот же ресурс или обмениваться информацией, это может привести к неразберихе и несогласованности. Задача параллельных вычислений заключается в решении этой проблемы. Некоторые решения используют "блокировки", аналогичные тем, что применяются в базах данных, но они могут вызывать собственные проблемы, такие как взаимная блокировка (deadlock). Другие решения – неблокирующие алгоритмы и Read-Copy-Update.