Cтраница 3
Эти данные необходимы для распределения загрузки между процессорами комплекса и для оценки выполнения требований по производительности, времени и вероятности решения отдельных функциональных задач. Исследуемая в САПО ЯУЗА-6 модель учитывает структуру вычислительного комплекса, методы организации вычислительного процесса, загрузку, наличие конфликтов в памяти, взаимную связь по информации при параллельном исполнении программ, ограниченные емкости буферных накопителей. К числу исходных данных относятся характеристики потоков заявок от объектов управления; характеристики КП, включающие длительности обслуживания заявок, перечень функциональных задач с указанием заявок, входящих в каждую задачу и последовательность исполнения заявок и задач; параметры вычислительных средств - количество процессоров и блоков оперативной памяти, их быстродействие, распределение задач по процессорам, структура приоритетов, структура и емкости буферов. В исходных данных должны быть указаны директивные сроки выполнения каждой функциональной задачи и допустимые вероятности нерешения задачи, а также требуемая Пропускная способность системы. [31]
![]() |
Граф предшествований для. [32] |
Как и в модели из предыдущего раздела, достаточной гарантией сериа-лизуемости является двухфазный протокол, в соответствии с которым установление блокировок для чтения и записи предшествует всем операторам разблокирования. Более того, справедливо и обратное утверждение, а именно, что для любой транзакции, в которой некоторый оператор UNLOCK предшествует установлению блокировки для чтения или записи, существует несериализуемое расписание, предусматривающее ее параллельное исполнение с некоторой другой транзакцией. Доказательство этих результатов мы предоставляем читателю в качестве упражнения. [33]
Более того, всякая данная формальная система программирования может допускать различные виды параллелизма, каждый из которых предполагает наличие особого способа управления реализующими эту систему процессами. Возможности для параллельного исполнения логических программ распадаются на несколько категорий. К первой категории, оказавшейся довольно приемлемой с точки зрения разработчика реализации, относится ИЛИ-параллелизм, в котором используется тот факт, что когда на активируемый вызов отвечают сразу несколько процедур, их можно вызывать и применять для исследования этого вызова параллельно. Получающиеся в результате параллельные вычисления можно строить независимо, за исключением того случая, когда у них появляются ссылки на одни и те же несвязанные переменные в их общей родительской среде, вследствие чего могут возникнуть конкурирующие присваивания; для устранения этого незначительного препятствия на пути к поистине независимому ИЛИ-параллелизму можно использовать специальные схемы организации стеков. ИЛИ-параллелизм должен сыграть полезную роль при поиске в базах данных, где один запрос может иметь большое число альтернативных решений; это - прямое следствие недетерминизма логических программ в том смысле, что они допускают целое множество вычислений. [34]
Хотя время между двумя обращениями к БД - чтением и записью - мало, но нет никакой гарантии, что за это время другая транзакция не вклинится в этот промежуток. Как видно из табл. 8.1, проблема по-прежнему не решена. Решение заключается в недопущении параллельного исполнения двух и более процессов ( транзакций), в которых выполняется чтение и изменение одних и тех же данных. [35]
По правилам ОрепМР в программе должна быть выделена область параллельного исполнения ( блок параллелизации) - одна или несколько. Для исполнения операторов блока параллелизации создается группа подпроцессов ( или нитей, или потоков исполнения), число которых назначается до начала блока или в директиве, открывающей блок. Поток исполнения, создавший группу, становится ведущим подпроцессом ( или мастером) группы. Внутри области параллельного исполнения число подпроцессов сохраняется неизменным. По выходу из блока параллелизации все подпроцессы группы, за исключением мастера, закрываются. Директивами ОрепМР в блоке параллелизации могут быть выделены блоки операторов, исполнение которых может быть поручено одному из подпроцессов группы. Например, оператор цикла может быть разделен на части так, чтобы каждая из них выполнялась отдельным подпроцессом. Независимые не итеративные блоки операторов также могут быть поручены различным подпроцессам. Операторы, параллельное выполнение которых невозможно или нежелательно, могут исполняться либо одним из подпроцессов группы, либо подпроцессом-мастером. Все директивы, управляющие исполнением, применимы только к блокам замкнутого кода. Области параллельного исполнения могут вкладываться друг в друга. В этом случае каждый подпроцесс из группы исполнения создает свою группу, в которой становится мастером. [36]
Интуитивно ясно, что такая ситуация ошибочна. Поскольку всегда имеется возможность исполнять транзакции по одной одновременно ( последовательно), разумно считать нормальным или предполагаемым результат транзакции, который мы получаем при отсутствии каких-либо иных параллельно исполняемых транзакций. Таким образом, параллельное исполнение нескольких транзакций корректно, если и только если их совместный результат будет тем же самым, что и при исполнении этих транзакций последовательно в некотором порядке. [37]
Давным-давно в операционных системах была разработана концепция процессов, чтобы отгородить пользователей друг от друга. Идея заключается в том, что у каждого пользователя есть свое адресное пространство и свой идентификатор UID, что позволяет ему получать доступ к файлам и другим ресурсам, принадлежащим ему, но не другим пользователям. Защиты ресурсов и одной части процесса от другой части процесса ( апплета) концепция процесса предоставить не может. Концепция потоков обеспечивает возможность параллельного исполнения нескольких задач в одном адресном пространстве процесса, но не предоставляет никакой защиты одного потока от другого. [38]
Большинство программ в МПС выполняются параллельно и требуют тщательной согласованности использования исходных и промежуточных данных, устройств вычислительной техники. Особенно важно осуществить проверку при различных сочетаниях исполнения программ комплекса одновременно функционирующими процессорами. Необходимо выявить тупиковые ситуации, при которых параллельные программы обращаются к одним и тем же ресурсам системы и не могут продолжить решения до их освобождения. Для обнаружения таких ошибок используется тест проверки параллельного исполнения программ. [39]
На практике это чаще всего и требуется. Однако существует целый ряд приложений, когда одновременно ( параллельно) исполняется несколько программ или различных прогонов одной и той же программы. В системе продажи авиабилетов, например, продавать билеты и изменять таким образом списки пассажиров и число свободных мест могут одновременно несколько агентов. Главная проблема состоит в том, что если не позаботиться о правилах, регулирующих доступ к базе данных двух или более программ, то не исключается возможность продажи билетов на одно и то же место двум пассажирам. Интуиция подсказывает нам, что не следует допускать параллельное исполнение двух процессов, которые читают и изменяют значение одного и того же объекта. [40]
Организация параллельных вычислительных процессов должна обеспечивать выполнение всех функций, необходимых при последовательном исполнении программ и, кроме того, учитывать ряд факторов, присущих одновременной работе процессоров и других устройств в вычислительной системе. Одна из основных особенностей при планировании обработки состоит в необходимости следить за состоянием всех процессоров МПК в момент, когда происходит назначение очередной заявки на освобождающийся процессор. Для этого диспетчер начиная с некоторого момента времени приписывает каждую из заявок к определенному процессору. Это может привести к тому, что образуется очередь ожидающих заявок к одному процессору, тогда как другие процессоры могут простаивать. Чтобы наиболее полно использовать возможности многопроцессорной структуры в системе организации вычислительного процесса, можно предусмотреть определение перечня задач и их компонент, допускающих параллельное исполнение, а также учет их взаимных связей. Кроме того, возникает задача обеспечения равномерной загрузки всех процессоров МПК, для чего необходимо уметь прогнозировать время выполнения программ и требуемые ресурсы. [41]
Затем проверяются все предпосылки. Если хотя бы одна из них выработает значение false, возбуждается соответствующее исключение и работа транзакции приостанавливается. Снова, если хотя бы одна постпосылка выработает результат false, возбуждается соответствующее исключение. В нормальном случае работа транзакции заканчивается с возможной выработкой соответствующего результата. Предпосылки и постпосылки создают гарантии, что работа транзакции начинается в условиях достоверного состояния базы данных и заканчивается также оставлением базы данных в достоверном состоянии. Это особенно важно в условиях параллельного исполнения нескольких транзакций, являющихся основным средством подачи заданий по работе с базой данных. [42]
По правилам ОрепМР в программе должна быть выделена область параллельного исполнения ( блок параллелизации) - одна или несколько. Для исполнения операторов блока параллелизации создается группа подпроцессов ( или нитей, или потоков исполнения), число которых назначается до начала блока или в директиве, открывающей блок. Поток исполнения, создавший группу, становится ведущим подпроцессом ( или мастером) группы. Внутри области параллельного исполнения число подпроцессов сохраняется неизменным. По выходу из блока параллелизации все подпроцессы группы, за исключением мастера, закрываются. Директивами ОрепМР в блоке параллелизации могут быть выделены блоки операторов, исполнение которых может быть поручено одному из подпроцессов группы. Например, оператор цикла может быть разделен на части так, чтобы каждая из них выполнялась отдельным подпроцессом. Независимые не итеративные блоки операторов также могут быть поручены различным подпроцессам. Операторы, параллельное выполнение которых невозможно или нежелательно, могут исполняться либо одним из подпроцессов группы, либо подпроцессом-мастером. Все директивы, управляющие исполнением, применимы только к блокам замкнутого кода. Области параллельного исполнения могут вкладываться друг в друга. В этом случае каждый подпроцесс из группы исполнения создает свою группу, в которой становится мастером. [43]