РАСШИРЕНИЕ СОГЛАСУЮЩЕГО ПРОТОКОЛА ДЛЯ ИНДИКАЦИИ СОСТОЯНИЯ ТРАНЗАКЦИИ
COHERENCE PROTOCOL AUGMENTATION TO INDICATE TRANSACTION STATUS

Уровень техники
В общем, настоящее изобретение относится к протоколам запросов и ответов и, прежде всего, к расширению согласующего протокола для индикации состояния транзакции.
Для удовлетворения растущих потребностей в рабочей нагрузке продолжает значительно возрастать число ядер центрального процессора (ЦП) на микросхеме и число присоединенных к совместно используемой памяти ядер ЦП. Растущее число ЦП, взаимодействующих при обработке одной рабочей нагрузки налагает значительные требования на масштабируемость программного обеспечения; например, защищенные традиционными семафорами совместно используемые очереди или структуры данных становятся горячими точками и приводят к подлинейным n-вариантным кривым масштабирования. Традиционно этому противостояли посредством реализации мелкомодульной блокировки в программном обеспечении, и с помощью межсоединений с малым запаздыванием/высокой пропускной способностью в аппаратных средствах. Реализация мелкомодульной блокировки для улучшения масштабируемости программного обеспечения может быть очень сложной и подверженной ошибкам, а при современных частотах ЦП, запаздывания аппаратных межсоединений ограничиваются физическими размерами микросхем и систем, а также скоростью света.
Была введена аппаратная транзакционная память (НТМ, или в этом обсуждении, просто ТМ), в которой называемая транзакцией группа команд, при рассмотрении со стороны других центральных процессоров (ЦП) и подсистемы ввода-вывода, воздействует элементарным способом на структуру данных в памяти (элементарная операция также известна в другой литературе как блокированная многопоточная или преобразованная в последовательную форму). Транзакция выполняется в оптимистичном варианте без получения блокировки, но возможным также является возникновение необходимости в прекращении и в повторном выполнении транзакции, если операция выполняющейся транзакции на ячейке памяти находится в противоречии с другой операцией на той же самой ячейке памяти. Ранее были предложены реализации программной транзакционной памяти для поддержки программной транзакционной памяти (ТМ).
Сущность изобретения
Варианты осуществления включают в себя способ, систему и машиночитаемый информационный носитель для реализации согласующего протокола. Запрос на данные отправляется к удаленному процессору. Процессор получает ответ от удаленного процессора, и ответ имеет состояние транзакции, свойственное удаленной транзакции на удаленном процессоре. Процессор добавляет состояние удаленной транзакции на удаленном процессоре в таблицу отслеживания взаимного вмешательства локальных транзакций. Состояние удаленной транзакции добавляется к транзакционному диагностическому блоку
Краткое описание нескольких видов на чертежах
Рассматриваемый в качестве вариантов осуществления объект изобретения, прежде всего, указан и недвусмысленно заявлен в пунктах формулы изобретения в конце технического описания. Упомянутые ранее и другие признаки и
преимущества вариантов осуществления являются очевидными из последующего подробного описания, рассматриваемого совместно с сопровождающими чертежами, на которых:
Фиг. 1 изображает схематическую блок-диаграмму типового окружения транзакционной памяти для множественных процессоров (ЦП)/ядер согласно варианту осуществления,
Фиг. 2 изображает схематическую блок-диаграмму, показывающую транзакционный процессор согласно варианту осуществления,
Фиг. 3 изображает схематическую блок-диаграмму типовых компонентов транзакционного процессора (ЦП), показанных на фиг. 1 и 2, согласно варианту осуществления,
Фиг. 4 изображает схематическую блок-диаграмму компьютерной системы, имеющей компоненты, подобные многопроцессорным системам, показанным на фиг. 1-3, для предоставления запросов и ответов в аппаратном окружении транзакционной памяти согласно варианту осуществления,
Фиг. 5 изображает типовые протокольные запрос и ответ согласно варианту осуществления,
Фиг. 6 изображает образцовый протокольный запрос согласно варианту осуществления,
Фиг. 7 изображает блок-схему генерации протокольного запроса посредством процессора, создающего запрос на данные согласно варианту осуществления,
Фиг. 8 изображает блок-схему обработки запроса посредством приемного/удаленного процессора, который принимает запрос и отправляет ответ согласно варианту осуществления,
Фиг. 9 изображает блок-схему, показывающую обработку транзакции посредством процессора согласно варианту осуществления,
Фиг. 10 изображает протокольный запрос и новый протокольный ответ согласно варианту осуществления,
Фиг. 11 изображает протокольный запрос на запись и новый ответ согласно варианту осуществления,
Фиг. 12 изображает блок-схему, показывающую обработку согласующего запроса посредством приемного/удаленного процессора, который принимает запрос согласно варианту осуществления,
Фиг. 13 изображает блок-схему, показывающую создание протокольного запроса и его обработку посредством запрашивающего процессора согласно варианту осуществления,
Фиг. 14 изображает блок-схему, показывающую обработку транзакции посредством процессора согласно варианту осуществления,
Фиг. 15 изображает блок-схему, показывающую, как процессор отвечает на индикацию вмешательства в накопительной таблице локального отслеживания взаимного вмешательства транзакций согласно варианту осуществления,
Фиг. 16 изображает блок-схему, показывающую, как процессор отвечает на индикацию вмешательства в накопительной таблице локального отслеживания взаимного вмешательства транзакций согласно варианту осуществления,
Фиг. 17 изображает способ обработки согласующего протокола согласно варианту осуществления, и
Фиг. 18 изображает машиночитаемый носитель согласно варианту осуществления.
Подробное описание
Многопроцессорные системы используют согласующие протоколы для поддержания взаимосогласованности между всеми кэшами в системе распределенной общей памяти. Когда делают запрос на данные от конкретного кэша, этот кэш выдает данные и обновляет свое состояние таким образом, что он более не имеет данных или, что данные не содержатся исключительно в нем. Если процессор находится в процессе транзакционного выполнения, и от его кэша запрашиваются данные, которые являются частью транзакции, то процессор прекращает транзакцию и отправляет данные.
Отсутствует какая-либо информация о том, вызвал ли запрос прекращение другой транзакции. В некоторых случаях является желательным уведомление исходного инициатора запроса о воздействии запроса на другую транзакцию для предоставления обратной связи и для предоставления формирователю инициатора запроса возможности адаптации его выполнения, например обнаружения сценариев динамической взаимоблокировки, а также адресации к другим понижающим производительность сценариям.
Согласно варианту осуществления согласующий протокол расширяется для включения в него дополнительной информации по состоянию транзакции. Когда процессор находится в процессе транзакционного выполнения, согласующий запрос может вызвать прекращение этого выполнения, например вследствие того, что данные являются частью транзакционного набора значений для считывания или записи, и обнаруживается конфликт. Согласующий протокольный запрос расширяется за счет дополнительной информации о том, что получающий согласующий запрос процессор прервал транзакцию во время транзакционного выполнения согласно вариантам осуществления.
Работа «Архитектура системы команд Power ISA™ версия 2.07» (Power ISA™ Version 2.07), опубликованная 22 мая 2013 от IBM и включенная в настоящий документ путем отсылки в полном объеме, предлагает типовую архитектуру системы команд (ISA) компьютера с сокращенной системой команд (RISC). Кроме того, руководство «Принципы работы Z-архитектуры» (z/Architecture Principles of Operation SA22-7832-09) (август 2012) от IBM, включенное в настоящий документ путем отсылки в полном объеме, предлагает типовую архитектуру системы команд для CISC (компьютера со сложной системой команд).
Исторически, компьютерная система или процессор имели только единственный процессор (иначе, обрабатывающий блок или центральный процессор). Процессор включает в себя процессор команд (IPU), устройство обработки ветвлений, устройство управления памятью и т.п. Такие процессоры были способны к единовременному выполнению единственного программного потока. Были разработаны операционные системы, способные работать с разделением времени процессора посредством диспетчеризации подлежащей выполнению на процессоре программы в течение некоторого промежутка времени и последующей диспетчеризации подлежащей выполнению на процессоре другой программы в течение другого промежутка времени. По мере развития технологии, к процессору зачастую добавлялись кэши подсистемы памяти, а также комплексная динамическая трансляция адресов, включающая в себя ассоциативные буферы трансляции (TLB). IPU, как таковой, зачастую упоминается как процессор. По мере продолжения развития технологии, весь процессор мог быть упакован на единственном полупроводниковом чипе или кристалле; такой процессор называют микропроцессором. Затем были разработаны процессоры, которые содержали несколько IPU; такие процессоры зачастую называют многопроцессорными системами. Каждый такой процессор многопроцессорной компьютерной системы (процессор) может включать в себя отдельные или совместно используемые кэши, интерфейсы памяти, системную шину, механизм преобразования адресов и т.п. Виртуальная машина и эмуляторы архитектуры системы команд (ISA) добавили к процессору уровень программного обеспечения, который предоставил виртуальной машине множественные «виртуальные процессоры» (иначе, процессоры) посредством разделенного по времени использования единственного IPU в единственном аппаратном процессоре. По мере дальнейшего развития технологии были разработаны многопоточные процессоры, обеспечивающие единственному аппаратному процессору, имеющему единственный многопоточный IPU, возможность одновременного выполнения потоков различных программ; тем самым каждый поток многопоточного процессора представляется операционной системе в качестве процессора. По мере дальнейшего развития технологии стало возможным размещение множественных процессоров (каждый из которых имеет IPU) на единственном полупроводниковом чипе или кристалле. Эти процессоры называют ядрами процессора или просто ядрами. Тем самым такие термины, например, как процессор, центральный процессор, обрабатывающее устройство, микропроцессор, сердцевина, ядро процессора, поток процессора и поток зачастую используют взаимозаменяемым образом. Аспекты вариантов осуществления настоящего документа могут быть осуществлены посредством произвольных процессоров, включающих в себя указанные выше, без отступления от представленных в настоящем документе принципов. Когда в настоящем документе используется термин «поток» или «процессорный поток», подразумевается, что особое преимущество варианта осуществления может быть реализовано в процессорном потоке.
Выполнение транзакции в вариантах осуществления на основе процессоров Intel
В руководстве «Справочник по программированию расширений системы команд архитектуры Intel» (Intel Architecture Instruction Set Extensions Programming Reference), от февраля 2012, включенном в настоящий документ путем отсылки в полном объеме, в главе 8 указано, помимо прочего, что в многопоточных применениях преимущество увеличения числа ядер ЦП может быть использовано для достижения более высокой производительности. Однако разработка многопоточных применений требует от программистов понимания и принятия во внимание совместного использования данных в среде множественных потоков. Доступ к совместно используемым данным обычно требует применения механизмов синхронизации. Такие механизмы синхронизации используют для обеспечения обновления множественными потоками совместно используемых данных посредством преобразования в последовательную форму операций, которые применяют к совместно используемым данным, зачастую с помощью критической секции, которая защищена блокировкой. Поскольку преобразование в последовательную форму ограничивает параллелизм, программисты пытаются ограничить издержки вследствие синхронизации.
Расширения транзакционной синхронизации Intel (Intel Transactional Synchronization Extensions) (Intel TSX) позволяют процессору динамически выявлять необходимость преобразования потоков в последовательную форму посредством защищенных блокировкой критических секций, и выполнять такое преобразование в последовательную форму только при наличии необходимости. Это позволяет процессору обнаруживать и использовать параллелизм, который скрыт при применении вследствие динамически ненужной синхронизации. С помощью Intel TSX задаваемые программистами области кода (также называемые «транзакционными областями» или просто «транзакциями») выполняются транзакционным способом. Если транзакционное выполнение завершается успешно, то все операции с памятью, выполненные в пределах транзакционной области, представляются произошедшими мгновенно при рассмотрении с позиции других процессоров. Процессор делает осуществляемые в пределах транзакционной области операции с памятью выполняемой транзакции видимыми для других процессоров только в том случае, когда происходит успешная фиксация, то есть, когда выполнение транзакции успешно завершается.
Этот способ зачастую называют элементарной фиксацией.
Intel TSX вводит два программных интерфейса для задания областей кода для транзакционного выполнения. Аппаратное исключение блокировок (Hardware Lock Elision) (HLE) представляет собой обратно совместимое расширение системы команд (содержат префиксы XACQUIRE и XRELEASE) для задания транзакционных областей. Ограниченная транзакционная память (Restricted Transactional Memory) (RTM) представляет собой новый интерфейс системы команд для программистов (содержит команды XBEGIN, XEND и XABORT) для описания транзакционных областей более гибким способом, нежели это возможно с помощью HLE. HLE подходит для программистов, которые предпочитают обратную совместимость обычной модели программирования взаимного исключения и хотят выполнять оснащенное HLE программное обеспечение на устаревшем оборудовании, но также хотят использовать преимущества возможности нового исключения блокировок на аппаратных средствах с поддержкой HLE. RTM подходит для программистов, которые предпочитают гибкий интерфейс аппаратным средствам транзакционного выполнения. Кроме того, Intel TSX также вводит команду XTEST. Эта команда позволяет программному обеспечению запрашивать, осуществляет ли логический процессор транзакционным способом выполнение в транзакционной области, заданной посредством HLE или RTM.
Поскольку успешное транзакционное выполнение обеспечивает элементарную фиксацию, процессор выполняет область кода в оптимистическом варианте без явной синхронизации. Если синхронизация была ненужной для этого конкретного выполнения, выполнение может быть зафиксировано без какого-либо межпоточного преобразования в последовательную форму. Если процессор не способен к элементарной фиксации, то оптимистическое выполнение терпит неудачу. Когда это происходит, процессор откатывает выполнение назад; данный процесс называют прекращением транзакции. При прекращении транзакции процессор сбрасывает все обновления, выполненные в используемой транзакцией области памяти, восстанавливает архитектурное состояние до вида, соответствующего полному отсутствию какого-либо оптимистического выполнения, и возобновляет выполнение нетранзакционным способом.
Процессор может выполнять прекращение транзакции по многим причинам. Первая причина прекращения транзакции проистекает из конфликтных доступов к памяти между выполняющим транзакционным способом логическим процессором и другим логическим процессором. Такие конфликтные доступы к памяти могут нарушить успешное транзакционное выполнение. Считываемые из транзакционной области адреса памяти составляют считываемый набор транзакционной области, а записываемые в пределах транзакционной области адреса составляют записываемый набор транзакционной области. Intel TSX поддерживает считываемые и записываемые наборы на уровне детализации, соответствующем строке кэша. Конфликтный доступ к памяти происходит в том случае, когда другой логический процессор или считывает ячейку памяти, которая является частью записываемого набора транзакционной области, или записывает в ячейку памяти, которая является частью либо считываемого, либо записываемого набора транзакционной области. Конфликтный доступ обычно означает, что для этой области кода требуется преобразование в последовательную форму. Поскольку Intel TSX обнаруживает конфликты данных на соответствующем строке кэша уровне детализации, несвязанные местоположения данных, размещенные в той же самой строке кэша, обнаруживаются как конфликты, которые приводят к прекращениям транзакций. Прекращения транзакций могут также произойти вследствие ограниченности транзакционных ресурсов. Например, объем данных, к которому получают доступ в области, может превысить заданную для конкретной реализации производительность. Кроме того, прекращения транзакций могут вызывать некоторые команды и системные события. Частые прекращения транзакций приводят к возникновению непродуктивных циклов и к снижению эффективности.
Аппаратное исключение блокировок
Аппаратное исключение блокировок (HLE) предоставляет обратно совместимый интерфейс системы команд для использования программистами транзакционного выполнения. HLE вводит две новые командные префиксные рекомендации: XACQUIRE и XRELEASE.
В рамках HLE программист добавляет префикс XACQUIRE перед командой, которая используется для получения, защищающей критическую секцию блокировки. Процессор обрабатывает префикс в качестве рекомендации к пропусканию записи, связанной с операцией получения блокировки. Несмотря на то, что получение блокировки имеет ассоциированную с блокировкой операцию записи, процессор не добавляет адрес блокировки к записываемому набору транзакционной области, равно он не делает к блокировке каких-либо запросов на запись. Вместо этого адрес блокировки добавляется к считываемому набору. Логический процессор входит в процесс транзакционного выполнения. Если блокировка была доступной перед получением командой префикса XACQUIRE, то все другие процессоры продолжают впоследствии рассматривать блокировку как доступную. Поскольку функционирующий транзакционным способом логический процессор не добавляет адрес блокировки к его записываемому набору и не выполняет видимых извне операций записи в блокировке, другие логические процессоры могут считывать блокировку без создания конфликта данных. Это позволяет другим логическим процессорам также вводить и одновременно выполнять защищенную блокировкой критическую секцию. Процессор автоматически обнаруживает любые конфликты данных, которые происходят в процессе транзакционного выполнения и, при необходимости, выполняет прекращение транзакции.
Хотя пропускающий процессор не выполняет каких-либо внешних операций записи в блокировке, аппаратные средства обеспечивают программный порядок операций на блокировке. Когда пропускающий процессор как таковой считывает значение блокировки в критической секции, это представляется, как если процессор получает блокировку, то есть считывание возвращает непропущенное значение. Такое поведение позволяет выполнению HLE быть функционально эквивалентным выполнению без префиксов HLE.
Префикс XRELEASE может быть добавлен перед командой, которая используется для разблокирования защищающей критическую секцию блокировки. Разблокирование блокировки включает в себя производство записи в блокировке. Если команда должна восстановить значение блокировки к значению, которое блокировка имела до снабжения префиксом XACQUIRE операции получения блокировки на той же самой блокировке, то процессор пропускает внешний запрос на запись, связанный с разблокированием блокировки, и не добавляет адрес блокировки к записываемому набору. В этом случае процессор пытается фиксировать процесс транзакционного выполнения.
С помощью HLE в случае, когда множественные потоки выполняют защищенные одной блокировкой критические секции, но не выполняют каких-либо конфликтующих операций на данных друг друга, потоки могут выполняться одновременно и без преобразования в последовательную форму. Несмотря на то, что программное обеспечение использует операции получения блокировки на общей блокировке, аппаратные средства распознают это, пропускают блокировку и выполняют критические секции на двух потоках, не требуя какой-либо коммуникации через блокировку, если такая коммуникация оказывается динамически ненужной.
Если процессор оказывается неспособен к выполнению области транзакционным способом, процессор выполняет область нетранзакционным способом и без пропускания. Оснащенное HLE программное обеспечение имеет те же самые гарантии прогресса продвижения, что и базовое, основанное на блокировках выполнение без HLE. Для успешного выполнения, HLE блокировка и код критической секции должны следовать определенным рекомендациям. Эти рекомендации затрагивают только производительность; отказ в следовании этим рекомендациям не приведет к функциональному отказу. Аппаратные средства без поддержки HLE игнорируют префиксные рекомендации XACQUIRE и XRELEASE и не выполняют какого-либо пропускания, поскольку эти префиксы соответствуют префиксам REPNE/REPE IA-32, которые игнорируются на командах, где являются допустимыми XACQUIRE и XRELEASE. Важно отметить, что HLE является совместимым с существующей, основанной на блокировках моделью программирования. Неправильное использование рекомендаций не вызывает функциональных ошибок, хотя оно может выявить уже имеющиеся в коде скрытые ошибки.
Ограниченная транзакционная память (RTM) предоставляет гибкий программный интерфейс для транзакционного выполнения. RTM предоставляет программистам три новые команды XBEGIN, XEND и XABORT для запуска, фиксирования и прекращения транзакционного выполнения.
Программист использует команду XBEGIN для задания начала транзакционной области кода, а команду XEND - для задания окончания транзакционной области кода. Если область RTM не могла быть успешно выполненной транзакционным способом, то команда XBEGIN принимает операнд, который предоставляет относительное смещение к возвратному адресу команды.
Процессор может прервать транзакционное выполнение RTM по нескольким причинам. Во многих случаях аппаратные средства автоматически обнаруживают условия транзакционного прекращения и перезапускают выполнение от возвратного адреса команды с архитектурным состоянием, соответствующим имеющемуся при запуске команды XBEGIN, и с регистром ЕАХ, обновленным для описания состояния прекращения.
Команда XABORT позволяет программистам явным образом прекращать выполнение области RTM. Команда XABORT принимает 8-разрядный текущий аргумент, который загружен в регистр ЕАХ и, таким образом, является доступным программному обеспечению после прекращения RTM. Команды RTM не имеют каких-либо ассоциированных с ними ячеек памяти для хранения данных. В то время как аппаратные средства не предоставляют гарантий относительно того, будет ли область RTM когда-либо успешно зафиксирована транзакционным способом, большинство следующих рекомендуемым директивам транзакций, как ожидается, успешно фиксируются транзакционным способом. Однако программисты должны всегда предоставлять альтернативную кодовую последовательность на возвратной ветви для гарантирования прогресса продвижения.
Это может быть столь же простым, как получение блокировки и выполнение заданной области кода нетранзакционным способом. Кроме того, транзакция, которая всегда прекращается на данной реализации, может завершиться транзакционным способом при последующей реализации. Поэтому программисты должны обеспечивать функциональное тестирование ветвей кода для транзакционной области и альтернативной кодовой последовательности.
Обнаружение поддержки HLE
Процессор поддерживает выполнение HLE, если CPUID.07H.EBX.HLE [bit 4] = 1. Однако приложение может использовать префиксы HLE (XACQUIRE и XRELEASE) без проверки наличия поддержки HLE процессором. Процессоры без поддержки HLE игнорируют эти префиксы и выполнят код без вхождения в процесс транзакционного выполнения.
Обнаружение поддержки RTM
Процессор поддерживает выполнение RTM, если CPUID.07H.EBX.RTM [bit 11] = 1. Приложение должно проверить наличие поддержки RTM процессором до использования команд RTM (XBEGIN, XEND, XABORT). Эти команды генерируют исключительное состояние #UD, когда используются на процессоре, который не поддерживает RTM.
Обнаружение команды XTEST
Процессор поддерживает команду XTEST, если он поддерживает HLE или RTM. Приложение должно проверить каждую из этих функциональных меток перед использованием команды XTEST. Эта команда генерирует исключительное состояние #UD, когда используется на процессоре, который не поддерживает HLE или RTM.
Запрос состояния транзакционного выполнения
Команда XTEST может быть использована для выявления транзакционного состояния заданной посредством HLE или RTM транзакционной области. Замечание: в то время как префиксы HLE игнорируются на процессорах, которые не поддерживают HLE, команда XTEST генерирует исключительное состояние #UD, когда используется на процессорах, которые не поддерживают HLE или RTM.
Требования для блокировок HLE
Для успешной фиксации выполнения HLE транзакционным способом блокировка должна удовлетворять конкретным требованиям, а доступ к блокировке должен следовать конкретным рекомендациям.
Снабженная префиксом XRELEASE команда должна восстанавливать значение пропущенной блокировки к значению, которое она имела перед получением блокировки. Это позволяет аппаратным средствам безопасно пропускать блокировки без добавления их к записываемому набору. Размер данных и адрес данных разблокирования блокировки (снабженной префиксом XRELEASE) команды должны соответствовать таковым для команды получения блокировки (снабженной префиксом XACQUIRE), и блокировка не должна пересекать границу строки кэша.
Программное обеспечение не должно записывать в пропущенную блокировку в транзакционной области HLE с помощью какой-либо иной команды, кроме снабженной префиксом XRELEASE команды, в противном случае такая запись может вызвать прекращение транзакции. Кроме того, рекурсивные блокировки (при которых поток многократно получает ту же самую блокировку без предварительного разблокирования блокировки) также могут вызывать прекращение транзакции. Следует обратить внимание на то, что программное обеспечение способно отслеживать результат пропущенного получения блокировки в критической секции. Такая операция считывания возвращает значение записи к блокировке.
Процессор автоматически обнаруживает нарушения этих рекомендаций и безопасно переходит к нетранзакционному выполнению без пропускания. Поскольку Intel TSX обнаруживает конфликты на уровне детализации строки кэша, записи в данных, расположенные на той же самой строке кэша, что и пропущенная блокировка, могут быть обнаружены как конфликты по данным посредством других логических процессоров, пропускающих ту же самую блокировку.
Транзакционное вложение
Как HLE, так и RTM поддерживают вложенные транзакционные области. Однако прекращение транзакции восстанавливает состояние операции, которая запустила транзакционное выполнение: либо наиболее удаленной снабженной префиксом XACQUIRE пригодной к выполнению в HLE команды, либо наиболее удаленной команды XBEGIN. Процессор обрабатывает все вложенные транзакции как одну транзакцию.
Вложение и исключение HLE
Программисты могут вкладывать области HLE вплоть до реализации заданной глубины MAX_HLE_NEST_COUNT. Каждый логический процессор отслеживает отсчет вложений внутренним образом, но этот отсчет является недоступным для программного обеспечения. Снабженная префиксом XACQUIRE пригодная к выполнению в HLE команда дает приращение отсчету вложений, а снабженная префиксом XRELEASE пригодная к выполнению в HLE команда уменьшает его значение. Логический процессор входит в процесс транзакционного выполнения, когда отсчет вложений переходит от ноля до единицы. Логический процессор пытается произвести фиксацию только при достижении отсчетом вложений нулевого значения. Прекращение транзакции может произойти при превышении отсчетом вложений значения MAX_HLE_NEST_COUNT.
В дополнение к поддержке вложенных областей HLE процессор также может пропускать множественные вложенные блокировки. Процессор отслеживает блокировку для пропускания, начинающуюся со снабженной префиксом XACQUIRE пригодной к выполнению в HLE команды для этой блокировки, и оканчивающуюся снабженной префиксом XRELEASE пригодной к выполнению в HLE командой для той же самой блокировки. Процессор способен в любой момент отслеживать число блокировок до значения MAX_HLE_ELIDED_LOCKS. Например, если реализация поддерживает MAX_HLE_ELIDED_LOCKS со значением два и, если программист вкладывает три идентифицированные в HLE критические секции (посредством выполнения снабженной префиксом XACQUIRE пригодной к выполнению в HLE команды на трех различных блокировках без выполнения вмешательства снабженной префиксом XRELEASE пригодной к выполнению в HLE команды на какой-либо из блокировок), то первые две блокировки пропускаются, а третья не пропускается (но добавляется к записываемому набору транзакции). Тем не менее, выполнение и далее продолжится транзакционным способом. После того, как был встречен префикс XRELEASE для одной из числа двух пропущенных блокировок, пропускается последующая блокировка, полученная посредством снабженной префиксом XACQUIRE пригодной к выполнению в HLE команды.
Процессор пытается фиксировать выполнение HLE, когда все пропущенные пары XACQUIRE и XRELEASE оказываются сопряженными, когда отсчет вложений принимает нулевое значение, а блокировки удовлетворяют требованиям. Если выполнение не может получить фиксацию элементарным образом, то выполнение переходит к нетранзакционному выполнению без пропускания, как если бы у первой команды не было префикса XACQUIRE.
Вложение RTM
Программисты могут вложить области RTM вплоть до специфичного для реализации значения MAX_RTM_NEST_COUNT. Логический процессор отслеживает отсчет вложений внутренним образом, но этот отсчет является недоступным для программного обеспечения. Команда XBEGIN дает приращение отсчету вложений, а команда XEND уменьшает значение отсчета вложений. Логический процессор пытается произвести фиксацию только при достижении отсчетом вложений нулевого значения. Прекращение транзакции происходит при превышении отсчетом вложений значения MAX_RTM_NEST_COUNT.
Вложение HLE и RTM
HLE и RTM предоставляют два альтернативных программных интерфейса для обеспечения общей функциональной способности транзакционного выполнения. Протекание процесса обработки транзакций является специфичным для конкретной реализации в том случае, когда HLE и RTM вкладываются друг в друга, например HLE в RTM или RTM в HLE. Однако во всех случаях, реализация должна содержать семантику HLE и RTM. Реализация может избрать игнорирование рекомендаций HLE при использовании в областях RTM, а также может вызывать прекращение транзакции при использовании команд RTM в областях HLE. В последнем случае переход от транзакционного к нетранзакционному выполнению происходит беспрепятственно, поскольку процессор повторно выполняет область HLE, фактически не делая пропускания, а затем выполняет команды RTM.
Описание состояния прекращения
RTM использует регистр ЕАХ для сообщения о состоянии прекращения программному обеспечению. После прекращения RTM регистр ЕАХ имеет следующее описание.
Состояние прекращения ЕАХ для RTM предоставляет только причины прекращений. Как таковое оно не кодирует, произошло ли прекращение или фиксация для области RTM. Значение ЕАХ может быть равно 0 после прекращения RTM. Например, команда CPUID, при использовании ее в области RTM, вызывает прекращение транзакции и может не удовлетворять требованиям по присваиванию значений каким-либо битам ЕАХ. Это может привести к значению ЕАХ равному 0.
Упорядочивание памяти RTM
Успешная фиксация RTM принуждает все операции с памятью в области RTM представляться выполняемыми элементарным образом. Успешно зафиксированная область RTM, состоящая из XBEGIN, сопровождаемого XEND, даже без операций с памятью в области RTM, имеет ту же самую упорядочивающую семантику, что и снабженная префиксом LOCK команда. Команда XBEGIN не имеет ограждающей семантики. Однако если выполнение RTM прекращается, то все обновления памяти изнутри области RTM отбрасываются и делаются невидимыми для какого-либо другого логического процессора.
Поддержка оснащенного RTM отладчика
По умолчанию, любое исключительное состояние отладки в области RTM вызывает прекращение транзакции и перенаправляет поток управления к возвратному адресу команды при восстановлении архитектурного состояния и присвоении биту 4 в ЕАХ значения. Однако архитектура RTM предоставляет дополнительную возможность для позволения отладчикам программного обеспечения прекращения выполнения на исключительных состояниях отладки.
Если бит 11 из DR7 и бит 15 из IA3_2DEBUGCTL_MSR оба имеют значение 1, любое прекращение RTM вследствие исключительного состояния отладки (#DB) или исключительного состояния точки прекращения (#ВР) вызывает выполнение отката и перезапуск от команды XBEGIN вместо возвратного адреса. В этом сценарии регистр ЕАХ также восстанавливается в прошлом состоянии на точке команды XBEGIN.
Соображения по программированию
Ожидается, что типичные отождествляемые программистами области успешно выполняются транзакционным способом и фиксируются. Однако Intel TSX не предоставляет какой-либо гарантии на это. Транзакционное выполнение может быть прервано по нескольким причинам. Для использования в полной мере транзакционных возможностей программисты должны следовать определенным рекомендациям для повышения вероятности успешной фиксации их транзакционного выполнения.
В настоящем разделе обсуждаются различные события, которые могут вызвать прекращения транзакций.
Архитектура обеспечивает, что обновления, выполненные в пределах транзакции, которая впоследствии прекращает выполнение, никогда не становятся видимыми. Только зафиксированные транзакционные выполнения инициируют обновление архитектурного состояния. Прекращения транзакций никогда не вызывают функциональных отказов, но сказываются только на производительности.
Соображения относительно команд
Программисты могут безопасно использовать любую команду в транзакции (HLE или RTM) и могут использовать транзакции на любом уровне полномочий. Однако некоторые команды всегда прекращают транзакционное выполнение и вызывают беспрепятственный и безопасный переход выполнения на нетранзакционную ветвь.
Intel TSX позволяет использование наиболее распространенных команд внутри транзакций без вызывания прекращений. Последующие операции в транзакции обычно не вызывают прекращение:
• Операции на регистре указателя команд, регистрах общего назначения (GPR) и метках состояния (CF, SF, PF, AF и ZF), а также
• Операции на регистрах ХММ и YMM и регистре MXCSR.
Тем не менее, программисты должны проявлять осторожность при объединении в транзакционной области операций SSE и AVX. Объединение команд SSE, получающих доступ к регистрам ХММ, и команд AVX, получающих доступ к регистрам YMM, может послужить причиной прекращения транзакций. Программисты могут использовать в транзакциях снабженные префиксами REP/REPNE строковые операции.
Тем не менее, длинные строки могут вызывать прекращения. Кроме того, использование команд CFD и STD может вызывать прекращения, если они изменяют значение метки DF. Тем не менее, если значение DF равняется 1, то команда STD не вызывает прекращения. Подобным образом, если значение DF равняется 0, то команда CFD не вызывает прекращения.
Команды, которые не перечислены здесь как способные вызывать прекращения, при использовании их в транзакции обычно не принуждают транзакцию прекращаться (варианты включают в себя, но не ограничиваются MFENCE, FFENCE, SFENCE, RDTSC, RDTSCP, и т.д.).
Следующие команды прекращают транзакционное выполнение на любой реализации:
• XABORT
• CPUID
• PAUSE
Кроме того, в некоторых реализациях, следующие команды могут всегда вызывать прекращения транзакций. Эти команды, как ожидается, обычно не используются в типичных транзакционных областях. Тем не менее, программисты не должны полагаться на эти команды для вызывания прекращения транзакции, поскольку вызывание ими прекращений транзакций зависит от конкретной реализации.
• Операции на Х87 и ММХ состояниях архитектуры. Данная категория включает в себя все команды ММХ и Х87, включая сюда команды FXRSTOR и FXSAVE.
• Обновление нестатусного участка EFFAGS: CFI, STI, POPFD, POPFQ, CFTS.
• Команды, которые обновляют сегментные регистры, отладочные регистры и/или регистры управления: MOV to DS/ES/FS/GS/SS, POP DS/ES/FS/GS/SS, EDS, FES, FFS, FGS, ESS, SWAPGS, WRFSBASE, WRGSBASE, LGDT, SGDT, LIDT, SIDT, LLDT, SLDT, LTR, STR, Far CALL, Far JMP, Far RET, IRET, MOV to DRx, MOV to CR0/CR2/CR3/CR4/CR8 и LMSW.
• Кольцевые переходы: SYSENTER, SYSCALL, SYSEXIT и SYSRET.
• TLB и управление кэшированием: CLFLUSH, INVD, WBINVD, INVLPG, INVPCID и команды памяти с невременной рекомендацией (MOVNTDQA, MOVNTDQ, MOVNTI, MOVNTPD, MOVNTPS и MOVNTQ).
• Сохранение состояния процессора: XSAVE, XSAVEOPT и XRSTOR.
• Прерывания: INTn, INTO.
• IO: IN, INS, REP INS, OUT, OUTS, REP OUTS и их варианты.
• VMX: VMPTRLD, VMPTRST, VMCLEAR, VMREAD, VMWRITE, VMCALL, VMLAUNCH, VMRESUME, VMXOFF, VMXON, INVEPT и INVVPID.
• SMX: GETSEC.
• UD2, RSM, RDMSR, WRMSR, HLT, MONITOR, MW AIT, XSETBV, VZEROUPPER, MASKMOVQ и V/MASKMOVDQU.
Соображения по среде выполнения
В дополнение к соображениям относительно команд, события в среде выполнения могут привести к прекращению транзакционного выполнения. Такие события могут произойти вследствие особенностей структуры доступа к данным или микро-архитектурным особенностям реализации. Последующий список не является всесторонним обсуждением всех возможных причин прекращения.
Следует блокировать любой дефект или прекращение в транзакции, которая должна быть открыта программному обеспечению. Транзакционное выполнение прекращается, и выполнение переходит к нетранзакционному выполнению, как если бы дефект или прекращение никогда не происходили. Если исключительное состояние не замаскировано, то незамаскированное исключительное состояние приведет к прекращению транзакции, и состояние примет вид, как если бы исключительное состояние никогда не происходило.
Синхронные события исключительного состояния (#DE, #OF, #NP, #SS, #GP, #BR, #UD, #AC, #XF, #PF, #NM, #TS, #MF, #DB, #BP/INT3), которые происходят в процессе транзакционного выполнения, могут привести к отсутствию фиксации выполнения транзакционным способом, и потребовать нетранзакционного выполнения. Эти события являются блокированными, как если бы они никогда не происходили. При использовании HFE, поскольку нетранзакционная ветвь выполнения кода является идентичной транзакционной ветви выполнения кода, эти события обычно вновь появляются, когда команда, которая вызвала исключительное состояние, повторно выполняется нетранзакционным способом, принуждая ассоциированные синхронные события быть поставленными надлежащим образом в нетранзакционном выполнении. Асинхронные события (NMI, SMI, INTR, IPI, PMI и т.д.), происходящие в процессе транзакционного выполнения могут принудить транзакционное выполнение к прекращению, и к переходу к нетранзакционному выполнению. Асинхронные события оказываются отложенными и обрабатываются после обработки транзакционного прекращения.
Транзакции поддерживают только операции типа, относящегося к обратной записи в кэшируемой памяти. Транзакция всегда может быть прекращена, если транзакция включает в себя операции на каком-либо другом типе памяти. Это включает в себя вызовы команд к типу памяти UC.
Доступы к памяти в пределах транзакционной области могут потребовать от процессора присваивания меток получения доступа и перезаписи в записях таблицы отсылочной страницы. Способ выполнения этой операции процессором является специфичным для конкретной реализации. Некоторые реализации могут позволять обновлениям этих меток становиться видимыми извне также и в том случае, когда транзакционная область впоследствии прекращается. Некоторые реализации TSX Intel могут принять решение о прекращении транзакционного выполнения при необходимости в обновлении этих меток. Кроме того, обход таблицы страниц процессора может генерировать доступы к своему собственному записанному транзакционным способом, но незафиксированному состоянию. Некоторые реализации Intel TSX в таких ситуациях могут принимать решение о прекращении выполнения транзакционной области. В любом случае, архитектура обеспечивает, что при прекращении выполнения транзакционной области записанное транзакционным способом состояние не становится архитектурно видимым в результате деятельности таких структур, как TLB.
Выполнение самомодифицирующегося кода транзакционным способом также может вызывать прекращения транзакций. Программисты должны продолжить следовать рекомендуемым Intel директивам для записи самомодифицирующегося и перекрестномодифицирующегося кода также и в случае использования HLE и RTM. В то время как реализация RTM и HLE обычно предоставляет достаточные ресурсы для выполнения общих транзакционных областей, ограничения реализации и чрезмерные размеры транзакционных областей могут принудить транзакционное выполнение к прекращению, и к переходу к нетранзакционному выполнению. Архитектура не предоставляет гарантии предоставления доступных ресурсов в объеме, достаточном для транзакционного выполнения, и не гарантирует успешного завершения транзакционного выполнения как такового.
Конфликтующие запросы к строке кэша, к которой получают доступ в пределах транзакционной области, могут воспрепятствовать успешному выполнению транзакции. Например, если логический процессор Р0 считывает строку А в транзакционной области, а другой логический процессор Р1 записывает строку А (как внутри, так и вовне транзакционной области), то логический процессор Р0 может совершить прекращение, если запись логического процессора Р1 служит помехой способности процессора Р0 к выполнению транзакционным способом.
Подобным образом, если Р0 записывает строку А в транзакционной области, а Р1 считывает или записывает строку А (как внутри, так и вовне транзакционной области), то Р0 может совершить прекращение, если доступ Р1 к строке А служит помехой способности процессора Р0 к выполнению транзакционным способом. Кроме того, поток данных с другой согласованностью может время от времени проявляться в качестве конфликтующих запросов и может вызывать прекращения. Хотя такие ложные конфликты и могут происходить, они, как ожидается, не должны быть в порядке вещей. Политика разрешения конфликтов, призванная выявлять Р0 или Р1 в качестве объекта прекращения в вышеупомянутых сценариях, является специфичной для конкретной реализации.
Типовые варианты осуществления выполнения транзакции
Согласно работе «АРХИТЕКТУРЫ ДЛЯ ТРАНЗАКЦИОННОЙ ПАМЯТИ» (ARCHITECTURES FOR TRANSACTIONAL MEMORY) - диссертации, представленной Факультету информатики и Комитету по последипломному образованию Стэнфордского университета в частичное выполнение требований к степени доктора философии Остином Макдональдом (Austen McDonald), в июне 2009, включенной в настоящий документ путем отсылки в полном объеме, по существу имеется три механизма, необходимые для реализации элементарной и изолированной транзакционной области: версионность, обнаружение конфликтов и состязательное управление.
Для достижения элементарного представления транзакционной области кода все выполняемые этой транзакционной областью кода модификации должны быть сохранены, и далее должны храниться изолированными от других транзакций до времени фиксации. Система выполняет эту задачу посредством реализации политики версионности. Существуют две парадигмы версионности: энергичная и ленивая. Энергичная система версионности хранит недавно сгенерированные транзакционные значения на месте и хранит предшествующие значения памяти на стороне, в так называемом журнале отмены. Ленивая система версионности временно хранит новые значения в так называемом буфере записи, копируя их в память только при фиксации. В любой системе кэш используется для оптимизации хранения новых версий.
Для обеспечения элементарного представления выполнения транзакции конфликты должны быть обнаружены и разрешены. Эти две системы, то есть энергичная и ленивая системы версионности, обнаруживают конфликты посредством реализации политики обнаружения конфликтов, которая может быть либо оптимистической, либо пессимистической. Оптимистическая система выполняет транзакции параллельно, делая проверку на конфликты только при фиксации транзакции. Пессимистическая система проверяет на конфликты при каждой загрузке с запоминанием. Подобно версионности, обнаружение конфликтов также использует кэш, отмечая каждую строку или как часть считываемого набора, или как часть записываемого набора, или как обоих. Эти две системы разрешают конфликты посредством реализации политики состязательного управления. Имеется несколько политик состязательного управления, некоторые из них более подходят для оптимистического обнаружения конфликтов, а некоторые из них более подходят для пессимистического. Ниже описаны некоторые типовые политики.
Поскольку каждая система транзакционной памяти (ТМ) нуждается как в обнаружении версий, так и в обнаружении конфликтов, их варианты порождают четыре различных исполнения ТМ: Энергичное-Пессимистическое (ЕР), Энергичное-Оптимистическое (ЕО), Ленивое-Пессимистическое (LP) и Ленивое-Оптимистическое (LO). Таблица 2 кратко описывает все четыре отличных исполнения ТМ.
Фиг. 1 и 2 изображают вариант многоядерного окружения ТМ. Фиг. 1 показывает несколько оснащенных ТМ ЦП (ЦП1 114а, ЦП2 114b, и т.д.) на одном кристалле 100, соединенных с помощью межсоединения 122 и находящихся под администрированием коммутационного управления 120а, 120b. Каждый из ЦП 114а, 114b (также называемый процессором) может иметь разделенный кэш, состоящий из кэша 116а, 166b команд для кэширования подлежащих выполнению команд из памяти, и кэша 118а, 118b данных с поддержкой ТМ для кэширования данных (операндов) ячеек памяти, подлежащих обработке посредством ЦП 114а, 114b (на фиг. 1, каждый ЦП 114а, 114b и его ассоциированные кэши обозначаются как 112а, 112b). В варианте осуществления кэши множественных кристаллов 100 связаны для поддержки согласованности кэша между кэшами множественных кристаллов 100. В варианте осуществления для хранения как команд, так и данных, как правило, используют единственный кэш вместо разделенного кэша. В вариантах осуществления кэши ЦП представляют собой один уровень кэширования в иерархической структуре кэша. Например, каждый кристалл 100 может использовать совместно используемый кэш 124 для совместного использования всеми ЦП на кристалле 100. В другом варианте осуществления каждый кристалл может иметь доступ к совместно используемому кэшу 124, который совместно используется всеми процессорами всех кристаллов 100.
Фиг. 2 показывает детали типового транзакционного ЦП 114, содержащего дополнения для поддержки ТМ. Транзакционный ЦП (процессор) 114 может включать в себя аппаратные средства для поддержки контрольных точек 126 регистра и специальные регистры 128 ТМ. Транзакционный кэш ЦП может иметь биты MESI 130, Tags 140 и Data 142 обычного кэша, но также и, например, биты R 132, показывающие, что строка была считана посредством ЦП 114 при выполнении транзакции, и биты W 138, показывающие, что строка была записана посредством ЦП 114 при выполнении транзакции.
Ключевой деталью для программистов в любой системе ТМ является взаимодействие нетранзакционных доступов с транзакциями. Согласно замыслу, транзакционные доступы скрыты друг от друга с использованием вышеописанного механизма. Однако взаимодействие между обычной, нетранзакционной загрузкой и транзакцией, содержащей новое значение для соответствующего адреса, подлежит дальнейшему рассмотрению. Кроме того, также должно быть исследовано взаимодействие между нетранзакционным сохранением с транзакцией, которая считывает соответствующий адрес. Указанные проблемы относятся к концепции изоляции базы данных.
Считается, что система ТМ реализует сильную изоляцию, иногда называемую сильной элементарностью, при которой каждая нетранзакционная загрузка с запоминанием действует как элементарная транзакция. Поэтому, нетранзакционные загрузки не могут видеть незафиксированные данные, а нетранзакционные сохранения вызывают нарушения элементарности в любых транзакциях, которые считывают соответствующий адрес. Считается, что система, в которой дело обстоит иным образом, реализует слабую изоляцию, иногда называемую слабой элементарностью.
Сильная изоляция зачастую является более желательной, нежели слабая изоляция, вследствие относительной простоты концептуальной проработки и реализации сильной изоляции. Кроме того, если программист упустил охватить транзакциями некоторые ссылки общей памяти, что привело к ошибкам, то при сильной изоляции программист зачастую обнаруживает упущение с использованием простого интерфейса отладки, поскольку программист видит, что нетранзакционная область вызывает нарушения элементарности. Кроме того, записанные в одной модели программы могут по-разному работать с различными моделями.
Кроме того, в аппаратной ТМ сильную изоляцию зачастую поддерживать легче, чем слабую изоляцию. При сильной изоляции, поскольку согласующий протокол уже управляет коммуникацией загрузки с запоминанием между процессорами, транзакции могут обнаруживать нетранзакционные загрузки с запоминанием и действовать соответственно. Для реализации сильной изоляции в программной транзакционной памяти (ТМ) нетранзакционный код должен быть изменен таким образом, что он включает в себя барьеры считывания и записи, что потенциально вредит производительности. Хотя были приложены большие усилия к устранению многих ненужных барьеров, такие методы зачастую являются сложными, а производительность обычно является существенно меньшей по сравнению с таковой для НТМ.
Таблица 2 иллюстрирует фундаментальное пространство проектных параметров транзакционной памяти (версионность и обнаружение конфликтов).
Энергичное-Пессимистическое (ЕР)
Описанное ниже первое исполнение ТМ известно как Энергичное-Пессимистическое. Система ЕР хранит свой записываемый набор «на месте» (отсюда название «энергичная») и, для поддержки отката, хранит старые значения перезаписанных строк в «журнале отмены». Процессоры используют биты W 138 и R 132 кэша для отслеживания считываемого и записываемого наборов, а также для обнаружения конфликтов при получение запросов на отслеживаемую загрузку. Возможно, наиболее примечательными вариантами систем ЕР в известной литературе являются LogTM и UTM.
Начало транзакции в системе ЕР во многом происходит как начало транзакции в других системах: tm_begin () принимает значение контрольной точки регистра и присваивает начальные значения любым регистрам состояния. Система ЕР также требует присваивания начальных значений журналу отмены, детали данного процесса зависят от формата журнала, но зачастую включают в себя присваивание начальных значений указателю базы журнала на области предварительно выделенной, собственной для потока памяти, а также сброс регистра защиты памяти журнала.
Версионность: В ЕР, вследствие способа функционирования энергичной версионности, переходы состояний MESI 130 (индикаторы строки кэша, соответствующие измененному, исключительному, совместно используемому и недопустимому состоянию кода) остаются, главным образом, неизменными. За пределами транзакции переходы состояний MESI 130 остаются совершенно неизменными. При считывании строки в транзакции, применяют стандартные переходы согласования (S (совместно используемый) ⎯> S, I (недопустимый) ⎯> S или I ⎯> Е (исключительный)), что выдает в качестве результата по мере необходимости пропуск загрузки, но и присваивает также значение биту R 132. Аналогично, запись строки применяет стандартные переходы (S ⎯» М, Е ⎯> 1,1 ⎯» М), что выдает в качестве результата по мере необходимости пропуск, но и присваивает также значение биту W 138 (записано). При первом записывании строки старая версия всей строки загружается, а затем записывается в журнал отмены для сохранения ее на случай, если текущая транзакция прекращается. Недавно записанные данные в этом случае хранятся «на месте» поверх старых данных.
Обнаружение конфликтов: Пессимистическое обнаружение конфликтов использует сообщения согласования, которыми обмениваются при пропусках или обновлениях для поиска конфликтов между транзакциями. Когда происходит пропуск считывания в пределах транзакции, другие процессоры получают запрос на загрузку, но они игнорируют запрос, если у них нет необходимой строки. Если другие процессоры имеют необходимую строку неупреждающим образом или строку R 132 (считывание), они понижают эту строку до S, и в определенных случаях, выдают перемещение от кэша к кэшу, если они имеют строку в состоянии М или Е MESI 130. Однако если кэш имеет строку W 138, то между этими двумя транзакциями обнаруживается конфликт, и требуется проведение дополнительного действия (действий).
Подобным образом, когда транзакция стремится обновить строку от совместно используемой до измененной (при первом записывании), транзакция выдает запрос на исключительную загрузку, который также используется для обнаружения конфликтов. Если принимающий кэш имеет строку неупреждающим образом, то строка признается недопустимой и, в определенных случаях, выдается перемещение от кэша к кэшу (состояния М или Е). Но, если строка представлена R 132 или W 138, обнаруживается конфликт.
Проверка: Поскольку обнаружение конфликтов выполняется на каждой загрузке, транзакция всегда имеет исключительный доступ к ее собственному записываемому набору. Поэтому проверка не требует какой-либо дополнительной работы.
Фиксация: Поскольку энергичная версионность хранит новую версию элементов данных на месте, процесс фиксации попросту очищает биты W 138 и R 132 и отвергает журнал отмены.
Прекращение: Когда транзакция откатывается, исходная версия каждой строки кэша в журнале отмены должна быть восстановлена; процесс называют «разворачиванием» или «применением» журнала. Он осуществляется во время операции tm_discard () и должен быть элементарным относительно других транзакций. Конкретно, записываемый набор должен по-прежнему использоваться для обнаружения конфликтов: данная транзакция имеет единственную правильную версию строк в ее журнале отмены, и запрашивающие транзакции должны ожидать правильной версии, которая восстанавливается из этого журнала. Такой журнал может быть применен с использованием аппаратной конечной машины или программного обработчика прекращения.
Энергичное-Пессимистическое исполнение имеет следующие характеристики: Фиксация является простой и, поскольку она производится на месте, очень быстрой. Подобным образом, проверка является пустой операцией. Пессимистическое обнаружение конфликтов обнаруживает конфликты рано, уменьшая тем самым число «обреченных» транзакций. Например, если две транзакции вовлечены в зависимость записи после считывания, то при пессимистическом обнаружении конфликтов эта зависимость обнаруживается немедленно. Однако при оптимистическом обнаружении конфликтов такие конфликты не обнаруживаются до фиксации выполняющей запись программы.
Энергичное-Пессимистическое исполнение имеет также характеристики: Как описано выше, при первом записывании строки кэша старое значение должно быть записано в журнал, что влечет дополнительные доступы к кэшу. Прекращения являются ресурсоемкими, поскольку они требуют отмены журнала. Для каждой строки кэша в журнале должна быть выдана загрузка, что возможно потребует углубления вплоть до оперативной памяти до перехода к следующей строке. Пессимистическое обнаружение конфликтов также предотвращает возникновение некоторых сериализуемых списков. Кроме того, поскольку конфликты обрабатываются по мере их возникновения, имеется потенциал для динамической взаимоблокировки, и для обеспечения прогресса продвижения должны использоваться осторожные состязательные управленческие механизмы.
Ленивое-Оптимистическое исполнение (LO)
Другим популярным исполнением ТМ является Ленивое-Оптимистическое исполнение (LO), которое сохраняет свой записываемый набор в «буфере записи» или «журнале отката» и обнаруживает конфликты во время фиксации (также использующее биты R 132 и 138 W).
Версионность: Равно как в системе ЕР, протокол MESI исполнения LO осуществляется за пределами транзакций. После попадания внутрь транзакции, считывание строки влечет стандартные переходы MESI, но также и присваивает значение биту R 132. Аналогично, запись строки присваивает значение биту 138 W строки, но обработка переходов MESI для исполнения LO отличается от таковой для исполнения ЕР. Во-первых, при ленивой версионности новые версии записанных данных сохраняются в иерархии кэша до фиксации, в то время как другие транзакции имеют доступ к старым версиям, доступным в памяти или в других кэшах. Чтобы сделать доступными старые версии, грязные строки (М строки) должны быть вытеснены при первом их записывании посредством транзакции. Во-вторых, не являются необходимыми какие-либо пропуски обновлений вследствие оптимистического признака обнаружения конфликтов: если транзакция имеет строку в состоянии S, она может просто записать в нее и обновить эту строку до состояния М, без согласования изменения с другими транзакциями, поскольку обнаружение конфликтов производится во время фиксации.
Обнаружение конфликтов и проверка: Для проверки транзакции и обнаружения конфликтов исполнение LO сообщает адреса упреждающим образом измененных строк другим транзакциям только при подготовке ее фиксации. При проверке процессор отправляет один, потенциально большой, сетевой пакет, содержащий все адреса в записываемом наборе. Данные не отправляются, но остаются в кэше агента фиксации, помеченные как грязные (М). Для создания этого пакета без поиска кэша для помеченных W строк используется простой битовый вектор, называемый «накопительным буфером», имеющий по одному биту на строку кэша для отслеживания этих упреждающим образом измененных строк. Другие транзакции используют этот адресный пакет для обнаружения конфликтов: если адрес найден в кэше и битам R 132 и/или W 138 присвоены значения, то конфликт инициируется. Если строка найдена, но ни R 132, ни W 138 не присвоены значения, то строка просто признается недопустимой, что является подобным обработке исключительной загрузки.
Для поддержания элементарности транзакции эти адресные пакеты должны быть обработаны элементарным образом, то есть никакие два адресных пакета не могут существовать одновременно с одинаковыми адресами. В системе LO это может быть достигнуто посредством простого получения глобального маркера фиксации перед отправкой адресного пакета. Является, однако, возможным также использование схемы двухфазной фиксации посредством начальной отсылки адресного пакета, сбора ответов, введения в действие упорядочивающего протокола (возможно, вначале самая старая транзакция), и фиксации, как только все ответы являются удовлетворительными.
Фиксация: Как только проверка произошла, фиксация не требует какой-либо специальной обработки: всего лишь очистки битов W 138 и 132 R и накопительного буфера. Записи транзакции уже отмечены как грязные в кэше, а копии в других кэшах этих строк признаются недопустимыми посредством адресного пакета. Другие процессоры могут тогда получать доступ к зафиксированным данным посредством обычного согласующего протокола.
Прекращение: Откат является столь же простым: поскольку записываемый набор содержится в пределах локальных кэшей, эти строки могут быть признаны недопустимыми, после чего очищаются биты W 138 и 132 R и накопительный буфер. Накопительный буфер позволяет находить строки W для их признания недопустимыми без потребности искать в кэше.
Ленивое-Оптимистическое исполнение имеет следующие характеристики: Прекращения являются очень быстрыми, не требуют каких-либо дополнительных загрузок или сохранений и вносят только локальные изменения. Может существовать большее число сериализуемых списков, чем можно найти в ЕР, что позволяет системе LO более агрессивно действовать в предположении, что транзакции являются независимыми, что может обеспечить более высокую производительность. Наконец, позднее обнаружение конфликтов может повысить вероятность прогресса продвижения.
Ленивое-Оптимистическое исполнение также имеет характеристики: Проверка занимает время глобальной связи, пропорциональное размеру записываемого набора. Обреченные транзакции могут растрачивать ресурсы, поскольку конфликты обнаруживаются только во время фиксации.
Ленивое-Пессимистическое исполнение (LP)
Ленивое-Пессимистическое исполнение (LP) представляет собой третье исполнение ТМ, которое располагается примерно между ЕР и LO: хранение недавно записанных строк в буфере записи, но обнаружение конфликтов при каждом доступе.
Версионность: Версионность является подобной, но не идентичной таковой для LO: считывание строки присваивает значение соответствующему биту R 132, запись строки присваивает значение соответствующему биту W 138, а накопительный буфер используется для отслеживания строк W в кэше. Кроме того, грязные (М) строки должны быть вытеснены при первом их записывании посредством транзакции, так же, как в случае LO. Тем не менее, поскольку обнаружение конфликтов является пессимистическим, при обновлении транзакционной строки от I, S ⎯» М должны быть выполнены исключительные загрузки, что отличается от исполнения LO.
Обнаружение конфликтов: Обнаружение конфликтов LP действует подобно таковому для ЕР: для поиска конфликтов между транзакциями используются сообщения согласования.
Проверка: Как и в случае ЕР, пессимистическое обнаружение конфликтов обеспечивает, что в любой точке выполняемая транзакция не имеет конфликтов ни с какой другой выполняемой транзакцией, таким образом, проверка является пустой операцией.
Фиксация: Фиксация не требует какой-либо специальной обработки: всего лишь очистки битов W 138 и 132 R и накопительного буфера, как и в случае LO.
Прекращение: Откат также походит на откат в случае LO: простое признание недопустимым записываемого набора с использованием накопительного буфера, а также очистка битов W и R и накопительного буфера.
Энергичное-Оптимистическое исполнение (ЕО)
LP имеет следующие характеристики: Как и в случае LO, прекращения являются очень быстрыми. Как и в случае ЕР, использование пессимистического обнаружения конфликтов уменьшает число «обреченных» транзакций. Как и в случае ЕР, некоторые сериализуемые списки не являются дозволенными, а обнаружение конфликтов должно быть выполнено при каждом неудачном обращении в кэш.
Последняя комбинация версионности и обнаружения конфликтов представлена Энергичным-Оптимистическим исполнением (ЕО). ЕО скорее не достигает уровня оптимального выбора для систем НТМ: поскольку новые транзакционные версии записываются на месте, другие транзакции не имеют иного выбора, кроме как замечать конфликты по мере того, как они происходят (то есть, когда происходят неудачные обращения в кэш). Но поскольку ЕО с обнаружением конфликтов ожидает до времени фиксации, вовлеченные транзакции становятся «зомби», продолжая выполняться и расходуя ресурсы, несмотря на свою «обреченность» к прекращению.
Исполнение ЕО показало себя полезным в STM, и реализовано в Bartok-STM и McRT. Для обеспечения считывания самого нового значения ленивая версионность STM должна проверять свой буфер записи при каждом считывании. Поскольку буфер записи не является аппаратной структурой, это является затратным, отсюда следует предпочтение для записи на месте энергичной версионности. Кроме того, поскольку проверка на конфликты в STM также является затратной, оптимистическое обнаружение конфликтов предлагает преимущество валового выполнения этой операции.
Состязательное управление
Откат транзакции после решения системы о прекращении данной транзакция был описан выше, но поскольку конфликт включает в себя две транзакции, следует рассмотреть такие темы, как выбор транзакции для прекращения, способ инициирования прекращения и время повторения прекращенной транзакции. Это темы, которые рассматриваются в состязательном управлении (СМ), являющемся ключевым компонентом транзакционной памяти. Ниже описаны политики относительно того, как системы инициируют прекращения, а также различные известные методы администрирования выбора прекращаемой транзакции в конфликте.
Состязательные управленческие политики
Политика состязательного управления (СМ) представляет собой механизм, который выявляет, какая вовлеченная в конфликт транзакция должна быть прекращена, и когда прекращенная транзакция должна быть повторена. Например, зачастую имеет место случай, когда немедленное повторение прекращенной транзакции не приводит к наилучшей производительности. С другой стороны, использование механизма задержки, который задерживает повторение прекращенной транзакции, может привести к лучшей производительности. В STM первыми попытались разрешить задачу нахождения лучших политик состязательного управления, и многие из обрисованных в общих чертах ниже политик были первоначально разработаны для STM.
Политики СМ для принятия решения привлекают много параметров, в число которых входят возрасты транзакций, размер считываемых и записываемых наборов, число предшествующих прекращений и т.д. Комбинации параметров для принятия таких решений являются бесконечными, но некоторые комбинации описаны ниже, примерно в порядке повышения сложности.
Для построения некоторой номенклатуры, прежде всего, следует обратить внимание на то, что в конфликте имеются две стороны: нападающая и защищающаяся. Нападающей стороной является транзакция, запрашивающая доступ к ячейке совместно используемой памяти. При пессимистическом обнаружении конфликтов нападающей является транзакция, выдающая загрузку или исключительную загрузку. В оптимистическом обнаружении конфликтов нападающей является транзакция, пытающаяся произвести проверку. Защищающейся в обоих случаях является транзакция, получающая запрос нападающей стороны.
Агрессивная политика СМ сразу и всегда повторяет либо нападающую, либо защищающуюся сторону. В LO агрессивность означает, что нападающая сторона всегда побеждает, и поэтому агрессивность иногда называют победами агента фиксации. Такая политика использовалась для самых ранних систем LO. В случае ЕР, агрессивность означает либо победу защищающейся, либо победу нападающей стороны.
Перезапуск конфликтующей транзакции, которая немедленно претерпевает другой конфликт, ведет к растрате ресурсов, а именно, полоса пропускания межсоединений заполняется неудачными обращениями в кэш. Вежливая политика СМ использует экспоненциальную задержку (но также может использоваться и линейная) перед перезапуском конфликтов. Для предотвращения зависания, то есть ситуации, когда процесс не имеет выделенных ему планировщиком ресурсов, экспоненциальная задержка значительно повышает вероятность успеха транзакции после нескольких n повторений.
Другой подход к разрешению конфликтов предусматривает беспорядочное прекращение нападающей или защищающейся стороны (политика под названием рандомизированная). Во избежание ненужной конкуренции такая политика может быть объединена с рандомизированной схемой задержки.
Тем не менее, осуществление случайного выбора при избрании прекращаемой транзакции может привести к прекращению транзакций, которые завершили «большую работу», что влечет растрату ресурсов. Во избежание таких растрат, при выявлении прекращаемой транзакции может быть принят во внимание завершенный на транзакции объем работы. Одним из показателей проделанной работы может быть возраст транзакции. Другие способы включают в себя Самый старый, Валовую ТМ, Размер имеет значение, Карму и Польку. Самый старый представляет собой простой способ метки времени, который прекращает младшую транзакцию в конфликте. Валовая ТМ использует эту схему. Способ Размер имеет значение походит на Самый старый, но в качестве приоритета вместо возраста транзакции используется число считанных/записанных слов; способ возвращается к Самому старому после заданного числа прекращений. Карма является подобной; в качестве приоритета используется размер записываемого набора. Откат в этом случае происходит после отступления на заданный промежуток времени. Прекращенные транзакции сохраняют свои приоритеты, будучи прерванными (отсюда название Карма). Полька работает как Карма, но вместо отступления на заданный промежуток времени, этот способ отступает на величину, каждый раз возрастающую по экспоненте.
Поскольку прекращения растрачивают ресурсы, логично утверждать, что приостановка нападающей стороны до тех пор, пока защищающаяся не закончит свою транзакцию, приводит к лучшей производительности. К сожалению, такая простая схема легко приводит к взаимоблокировке.
Для решения этой проблемы могут использоваться методы предотвращения взаимоблокировки. Жадный алгоритм использует два правила для предотвращения взаимоблокировки. Первое правило: если первая транзакция Т1 имеет более низкий приоритет, чем вторая транзакция Т0, или если Т1 ожидает другой транзакции, то Т1 прекращается при конфликте с Т0. Второе правило: если Т1 имеет более высокий приоритет, чем Т0 и не находится в ожидании, то Т0 ожидает до тех пор, когда Т1 фиксируется, прекращается или начинает ожидание (в этом случае применяется первое правило). Жадный алгоритм предоставляет некоторые гарантии относительно временных границ для выполнения набора транзакций. Одно из исполнений ЕР (LogTM) использует подобную жадному алгоритму политику СМ для достижения приостановки при предотвращении консервативной взаимоблокировки.
Типовые правила согласования MESI предусматривают четыре возможных состояния, в которых может находиться строка кэша многопроцессорной системы кэша: М, Е, S, и I, задаваемые следующим образом:
Измененное (М): Строка кэша присутствует только в текущем кэше и является грязной; ее значение из оперативной памяти было изменено. Кэш требуется для записи данных обратно в оперативную память в некоторый момент времени в будущем перед разрешением какого-либо другого считывания (более не допустимого) состояния оперативной памяти. Обратная запись изменяет состояние строки на исключительное.
Исключительное (Е): Строка кэша присутствует только в текущем кэше, но является чистой; она согласована с оперативной памятью. Состояние строки может быть изменено на совместно используемое в любое время, в ответ на запрос на считывание. Альтернативно, оно может быть изменено на измененное состояние при записи в нее.
Совместно используемое (S): Указывает на то, что эта строка кэша может быть сохранена в других кэшах машины и является «чистой»; она согласована с оперативной памятью. Строка может быть отброшена (состояние изменено на недопустимое) в любое время.
Недопустимое (I): Указывает, что эта строка кэша является недопустимой (неиспользуемой).
Индикаторы состояния согласованности ТМ (R 132, W 138) могут быть предоставлены для каждой строки кэша закодированными в битах согласованности MESI или в дополнение к ним. Индикатор R 132 указывает, что текущая транзакция произвела считывание из данных строки кэша, а индикатор W 138 указывает, что текущая транзакция произвела запись в данные строки кэша.
В другом аспекте исполнения ТМ система разработана с использованием транзакционных накопительных буферов. Американский патент № 6 349 361 под названием «Способы и устройство переупорядочения и переименования ссылок на ячейку памяти в системе многопроцессорного компьютера» (Methods and Apparatus for Reordering and Renaming Memory References in a Multiprocessor Computer System), зарегистрированный 31 марта 2000 и включенный в настоящий документ путем отсылки в полном объеме, предлагает способ для переупорядочения и переименования ссылок на ячейку памяти в системе многопроцессорного компьютера, имеющего, по меньшей мере, первый и второй процессор. Первый процессор имеет первый закрытый кэш и первый буфер, а второй процессор имеет второй закрытый кэш и второй буфер. Способ включает в себя операции для каждого множества пропускаемых, полученных первым процессором запросов на хранение, выполняемые с целью сохранения элемента данных путем исключительного получения содержащей элемент данных строки кэша посредством первого закрытого кэша, и сохранения элемента данных в первом буфере. После получения первым буфером запроса на загрузку от первого процессора относительно загрузки конкретного элемента данных, конкретный элемент данных поставляется к первому процессору из числа сохраняемых в первом буфере данных на основании упорядоченной последовательности операций загрузки с запоминанием. После получения первым кэшем запроса на загрузку от второго кэша для заданного элемента данных, обозначается состояние ошибки, а текущее состояние по меньшей мере одного из процессоров сбрасывается к более раннему состоянию, когда запрос на загрузку для заданного элемента данных соответствует данным, сохраненным в первом буфере.
Главные компоненты реализации одной такой функции транзакционной памяти представлены регистровым файлом транзакционного резервного копирования для сохранения содержания предшествующего транзакции GR (общего регистра), каталогом кэша для отслеживания строк кэша, к которым получают доступ в процессе транзакции, кэшем сохранений для буферизации сохранений до окончания транзакции и встроенными рутинными операциями для выполнения различных комплексных функций. В настоящем разделе описана подробная реализация.
Вариант осуществления корпоративного сервера IBM zEnterprise ECU
Корпоративный сервер IBM zEnterprise ECU вводит процесс (ТХ) транзакционного выполнения в транзакционной памяти и частично описан в статье «Транзакционная архитектура памяти и ее реализация для z-системы IBM» (Transactional Memory Architecture and Implementation for IBM System z), на стр. 25-36 сборника, представленного на MICRO-45, 1-5 декабря 2012, Ванкувер, Британская Колумбия, Канада, предоставляемой IEEE Computer Society Conference Publishing Services (CPS), и включенной в настоящий документ путем отсылки в полном объеме.
Таблица 3 показывает типовую транзакцию. Для начинающихся с TBEGIN транзакций не обеспечивается успешное завершение когда-либо с TEND, поскольку они могут испытывать прекращающее условие при каждой попытке выполнения, например вследствие повторяющихся конфликтов с другими ЦП. Это требует поддержки программой возвратной ветви для выполнения той же операции нетранзакционным способом, например при помощи традиционных блокирующих схем. Это накладывает значительную нагрузку на группы программирования и проверки программного обеспечения, прежде всего, в случаях, когда возвратная ветвь не генерируется автоматически посредством надежного компилятора.
Требование обеспечения возвратной ветви для транзакций с прекращенным выполнением (ТХ) транзакции может быть обременительным. Многие действующие на совместно используемых структурах данных транзакции предполагаются короткими, затрагивающими только несколько отличных ячеек памяти и использующими только простые команды. Для таких транзакций IBM zEnterprise ЕС 12 вводит понятие ограниченных транзакций, при нормальных условиях ЦП 114 обеспечивает, в конечном счете, успешное окончание ограниченных транзакций, хотя и не задает строгий предел для числа необходимых повторных выполнений операции. Ограниченная транзакция запускается командой TBEGINC, и заканчивается обычной TEND. Реализация задачи в качестве ограниченной или неограниченной транзакции обычно приводит к сопоставимой в значительной мере производительности, но ограниченные транзакции упрощают разработку программного обеспечения, устраняя необходимость возвратной ветви. Архитектура процесса транзакционного выполнения IBM далее описана в статье «z-Архитектура, принципы работы» (z/Architecture, Principles of Operation), десятый выпуск SA22-7832-09, опубликованный в сентябре 2012 от IBM, включенный в настоящий документ путем отсылки в полном объеме.
Ограниченная транзакция запускается командой TBEGINC. Инициируемая TBEGINC транзакция должна следовать списку программных ограничений, в противном случае программа получает неподдающееся фильтрованию прерывание по нарушению ограничения. Типовые ограничения могут включать в себя, но не быть ими ограниченными, следующие случаи: транзакция может выполнять максимум 32 команды, весь текст команды должен находиться в пределах 256 последовательных байтов памяти; транзакция содержит только обращенные вперед относительные ветвления (то есть никаких операторов цикла или вызовов подпрограмм); транзакция может получить доступ максимум к 4 выровненным восьмикратным машинным словам (восьмикратное машинное слово состоит из 32 байтов) памяти; а также ограничение системы команд для исключения сложных команд, таких как десятичные операции или операции с плавающей точкой. Ограничения выбирают таким образом, что могут быть выполнены многие обычные операции, такие как двунаправленные операции ведения списка/удаления, включающие в себя чрезвычайно сильную концепцию элементарного планирования путем сравнения с обменом до 4 выровненных восьмикратных машинных слов. В то же время, ограничения выбирают достаточно консервативными таким образом, что будущие реализации ЦП способны обеспечивать успех транзакции без необходимости в регулировке ограничений, поскольку в противном случае, это приведет к несовместимости программного обеспечения.
На серверах zEC12 IBM TBEGINC, главным образом, ведет себя как XBEGIN в TSX или TBEGIN, за исключением того, что отсутствуют управление регистром с плавающей точкой (FPR) и поля фильтрации прерывания программы, а элементы управления считаются равными нулю. При прекращении транзакции адрес команды возвращается непосредственно к TBEGINC вместо последующей команды, что отображает непосредственное повторное выполнение операции и отсутствие ветви прекращения для ограниченных транзакций.
Вложенные транзакции не разрешены в пределах ограниченных транзакций, но если команда TBEGINC происходит в пределах неограниченной транзакции, она обрабатывается как открывающая новый неограниченный уровень вложенности точно так же, как в случае TBEGIN. Это может произойти, например, если неограниченная транзакция вызывает подпрограмму, которая использует ограниченную транзакцию внутренним образом.
Поскольку фильтрация прерывания является неявно выключенной, все исключения в процессе выполнения ограниченной транзакции приводят к прерыванию в операционной системе (OS). Возможное успешное окончание транзакции полагается на способность ОС к подкачке в оперативную память самое большее 4 страниц, затронутых какой-либо ограниченной транзакцией. ОС должна также обеспечивать интервалы времени, достаточно продолжительные для предоставления транзакции возможности завершения.
Таблица 4 показывает ограничено-транзакционную реализацию кода в Таблице 3 в предположении, что ограниченные транзакции не взаимодействуют с другим основанным на блокировке кодом. Поэтому не показано какое-либо тестирование блокировки, но оно может быть добавлено в случае смешивания ограниченных транзакций и основанного на блокировке кода.
При неоднократной реализации некорректной работы выполняется эмуляция программного обеспечения с использованием милликода в качестве части встроенного программного обеспечения системы. Выгодным образом, ограниченные транзакции имеют желательные свойства вследствие снятия ими нагрузки с программистов.
Со ссылкой на фиг. 3, процессор IBM zEnterprise ЕС 12 вводит функцию транзакционного выполнения. Процессор может декодировать 3 команды на тактовый цикл; простые команды диспетчеризируются как единичные микрооперации, а более сложные команды расщепляются на множественные микрооперации. Микрооперации (микрокоманды 232b) записываются в объединенную очередь 216 задач, откуда они могут быть выданы не по порядку. В каждом цикле может быть выполнено до двух операций с фиксированной точкой, одна с плавающей точкой, две операции загрузки и хранения, а также две команды перехода. Глобальная таблица завершения (GCT) 232 содержит каждую микрооперацию и глубину (TND) 232а вложения транзакции. GCT 232 записывается с упорядочиванием на время декодирования, отслеживает состояние выполнения каждой микрооперации 232b, и завершает команды, когда все микрооперации 232b самой старой группы команды оказываются успешно выполненными.
Кэш 240 данных уровня 1 (L1) представляет собой 96 КБ (килобайтный) 6-канальный ассоциативный кэш с 256-байтовыми строками кэша и с функциональным запаздыванием в 4 цикла, соединенный с закрытым 1 МБ (мегабайтовым) 8-канальным ассоциативным кэшем 268 данных 2-го уровня (L2) со штрафом за 7 циклов функционального запаздывания для пропусков L1 240. Кэш L1 240 представляет собой, самый близкий к процессору кэш, а кэш Ln - кэш на энном уровне кэширования. Как L1 240, так и L2 268 кэши являются кэшами сквозной записи. Шесть ядер на каждой микросхеме центрального процессора (ЦП) совместно используют 48 МБ 3-го уровня кэш отдельной записи, и шесть микросхем ЦП присоединены к внекристальному кэшу 384 МБ 4-го уровня, упакованному совместно на стеклокерамическом многокристальном модуле (МСМ). До 4 многокристальных модулей (МСМ) могут быть присоединены к согласованной симметричной многопроцессорной системе (SMP), имеющей до 144 ядер (не все ядра являются доступными для выполнения потребительской рабочей нагрузки).
Согласованностью управляют с помощью варианта протокола MESI. Строки кэша могут иметь принадлежность только для чтения (совместно используемые) или исключительную; L1 240 и L2 268 являются кэшами сквозной записи и, таким образом, не содержат грязных строк. Кэши L3 272 и L4 (не показаны) являются кэшами отдельной записи, и отслеживают грязные состояния. Каждый кэш является охватывающим для всех связанных с ним кэшей нижнего уровня.
Запросы согласования называют «перекрестными запросами» (XI) и отправляют иерархически от более высокого уровня до кэшей низшего уровня, а также между L4. Когда одно ядро пропускает L1 240 и L2 268 и запрашивает строку кэша от его локального L3 272, L3 272 проверяет, владеет ли он строкой, и при необходимости, отправляет XI во владеющий в настоящее время L2 268/L1 240, находящийся в подчинении у данного L3 272, для обеспечения согласованности прежде, чем он возвратит строку кэша инициатору запроса. Если запрос также пропускает L3 272, L3 272 отправляет запрос к L4 (не показан), который добивается согласованности посредством отправки XI ко всем необходимым L3, находящимся в подчинении у данного L4, и к соседним L4. Затем L4 отвечает на запрос L3, который отправляет ответ на L2 268/L1 240.
Следует обратить внимание на то, что вследствие правила охватывания иерархии кэша, иногда строки кэша получают XI запросы от кэшей низшего уровня вследствие вытеснений на высокоуровневых кэшах, вызванных переполнением по взаимосвязанности в результате запросов на другие строки кэша. Эти XI запросы можно назвать «LRU XI», где LRU обозначает последний по времени использования.
Следует упомянуть еще один тип XI запросов: XI понижающий переводит принадлежность кэша от исключительной в состояние только для считывания, а XI исключающий переводит принадлежность кэша от исключительного в недопустимое состояние. XI понижающий и XI исключающий требуют ответа, возвращаемого отправителю XI. Целевой кэш может «принять» эти XI или отправить «отклоняющий» ответ, если он сначала должен вытеснять грязные данные прежде, чем принять XI. Кэши L1 240/L2 268 являются кэшами сквозной записи, но могут отклонять XI понижающий и XI исключающий, если они имеют сохранения в их очередях сохранения, которые должны быть отправлены в L3 до понижения исключительного состояния. Отклоненный XI повторяется отправителем. XI только для считывания отправляется в кэши, которые владеют строкой только для считывания; для таких XI не является необходимым какой-либо ответ, поскольку они не могут быть отклонены. Детали протокола SMP подобны описанным для IBM z10 П. Маком (Р. Мак), К. Уолтерсом (С. Walter) и Г .Стрейтом (G. Strait), в статье «Микроархитектура подсистемы кэша процессора в системе IBM z10» (IBM System z10 processor cache subsystem microarchitecture), Журнал научных исследований IBM, том 53:1, 2009, включенной в настоящий документ путем отсылки в полном объеме.
Транзакционное выполнение команды
Фиг. 3 изображает типовые компоненты типового окружения ЦП 112, включающего в себя ЦП 114 и кэши/компоненты, с которыми он взаимодействует (подобные изображенным на фиг. 1 и 2). Устройство 208 (IDU) декодирования команд отслеживает текущую глубину 212 (TND) вложения транзакции. Когда IDU 208 получает команду TBEGIN, глубина вложения 212 увеличивается, и наоборот, уменьшается при получении команд TEND. Глубина вложения 212 записывается в GCT 232 для каждой диспетчеризированной команды. Когда TBEGIN или TEND декодируются на упреждающей ветви, которая позже сбрасывается, глубина вложения 212 IDU 208 обновляется от самой свежей несбрасываемой записи GCT 232. Транзакционное состояние также записывается в очереди 216 задач для использования операционными устройствами, главным образом, устройством 280 загрузки и хранения (LSU), которое также имеет включенным в состав LSU 280 вычислитель 236 исполнительного адреса. Команда TBEGIN может задавать транзакционный диагностический блок (TDB) для записи информации о состоянии в случае, когда транзакция прекращается до достижения команды TEND.
Подобно глубине вложения, IDU 208/GCT 232 совместно отслеживает шаблоны модификации регистра доступа/регистра с плавающей точкой (AR/FPR) через вложенное множество транзакций; IDU 208 может размещать запрос на прекращение в GCT 232, когда команда модификации AR/FPR декодируется, а шаблон модификации блокирует этот процесс. Когда команда становится практически завершенной, завершение блокируется и транзакция прекращается. Другие ограниченные команды обрабатываются подобным образом, включая и TBEGIN при декодировании в пределах ограниченной транзакции или при превышении максимальной глубины вложения.
Наиболее удаленный TBEGIN расщепляется на множественные микрооперации в зависимости от шаблона хранения GR; каждая микрооперация 232b (включая сюда, например, uop 0, uop 1 и uop 2) выполняется посредством одного из двух арифметических устройств (FXU) 220 для выполнения операций с фиксированной точкой для сохранения пары GR 228 в специальном регистровом файле 224 транзакционного резервного копирования, который используется для последующего восстановления содержания GR 228 в случае прекращения транзакции. TBEGIN также порождает микрооперации 232b для выполнения теста доступности для TDB, если таковой задан; адрес сохраняется в регистре особого назначения для последующего использования в случае прекращения. При декодировании наиболее удаленного TBEGIN адрес команды и текст команды TBEGIN также сохраняются в регистрах особого назначения для последующей потенциальной обработки прекращения.
TEND и NTSTG являются единственными микрооперационными 232b командами; NTSTG (нетранзакционное сохранение) обрабатывается подобно нормальному сохранению за исключением того, что оно отмечается как нетранзакционное в очереди 216 задач таким образом, что LSU 280 может обрабатывать его соответственно. TEND является пустой операцией во время выполнения; окончание транзакции осуществляется при завершении TEND.
Как упомянуто, находящиеся в пределах транзакции команды отмечаются как таковые в очереди 216 задач, но в остальном, выполняются практически неизменными; LSU 280 выполняет отслеживание изоляции, как описано в следующем разделе.
Поскольку декодирование является упорядоченным, и поскольку IDU 208 отслеживает текущее транзакционное состояние и записывает его в очередь 216 задач, наряду с каждой командой от транзакции, выполнение TBEGIN, TEND и команд до, в пределах, и после транзакции может быть осуществлено в произвольном порядке. Является даже возможным (хотя маловероятным), что TEND выполняется ранее всей транзакции, a TBEGIN выполняется последним. Порядок выполнения программы восстанавливается посредством GCT 232 во время завершения. Длина транзакций не ограничивается размером GCT 232, поскольку регистры (GR) 228 общего назначения могут быть восстановлены из резервного регистрового файла 224.
В процессе выполнения события регистрации (PER) программных событий фильтруются на основании управления подавлением событий, а событие PER TEND обнаруживается, если оно было активировано. Подобным образом, во время нахождения в транзакционном режиме, генератор псевдослучайных величин может вызывать случайные прекращения при его активации посредством управления диагностированием транзакций.
Отслеживание для транзакционной изоляции
Устройство 280 загрузки и хранения отслеживает строки кэша, к которым был получен доступ в процессе транзакционного выполнения, и инициирует прекращение, если XI от другого ЦП (или LRU-XI) конфликтует с требованием по ресурсам. Если конфликтующий XI является XI исключающим или XI понижающим, LSU 280 отклоняет XI обратно к L3 272 в расчете на окончание транзакции прежде, чем L3 272 повторит XI. Такое «жесткое противоборство» является очень эффективным в условиях сильной конкуренции транзакций. С целью предотвращения зависаний, когда два ЦП жестко борются друг с другом, реализуется счетчик отказов XI, который инициирует прекращение транзакции по достижении порогового значения.
Каталог кэша L1 240 традиционным образом реализуется на основе статической оперативной памяти (SRAM). Для реализации транзакционной памяти допустимые биты 244 (64 строки х 6 каналов) каталога перемещаются в нормальные логические замки и дополняются еще двумя битами на строку кэша: битами считывания из ТХ 248 и ТХ-грязными битами 252.
Считанные из ТХ 248 биты сбрасываются, когда декодируется новый наиболее удаленный TBEGIN (который является сблокированным с предшествующей, все еще отложенной транзакцией). Считанным из ТХ 248 битам присваиваются значения во время выполнения каждой команды загрузки, которая отмечена как «транзакционная» в очереди задач. Следует обратить внимание на то, что это может привести к завышению оценки, если упреждающие загрузки выполняются, например, на ветви непредсказанного перехода. Альтернатива для присваивания значения считанному из ТХ 248 биту во время завершения загрузки является слишком дорогой для кремниевой области, поскольку множественные загрузки могут завершаться в одно время, требуя нескольких портов считывания для очереди загрузки.
Сохранения выполняются так же, как в нетранзакционном режиме, но метка транзакции размещается в записи команды сохранения в очереди (STQ) 260 сохранений. Во время обратной записи, когда данные от STQ 260 записываются в L1 240, ТХ-грязному биту 252 в L1-каталоге 256 присваивается значение для записанной строки кэша. Обратная запись сохранения в L1 240 происходит только после того, как команда сохранения завершилась, и за цикл обратно записывается самое большее одно сохранение. Перед завершением и обратной записью, загрузки могут получить доступ к данным от STQ 260 посредством буферизации и передачи; после обратной записи ЦП 114 (фиг. 2) может получить доступ к обновленным упреждающим образом данным в L1 240. Если транзакция заканчивается успешно, грязные ТХ биты 252 из всех строк кэша очищаются, и также метки ТХ еще записанных сохранений очищаются в STQ 260, что эффективно преобразует отложенные сохранения в нормальные сохранения.
При прекращении транзакции все отложенные транзакционные сохранения в STQ 260, даже уже завершенные, признаются недопустимыми. Все строки кэша, которые были изменены транзакцией в L1 240, то есть имеют у себя ТХ-грязный бит 252, имеют свои биты достоверности выключенными, что эффективно мгновенно удаляет их из кэша L1 240.
Архитектура требует до завершения новой команды поддержания изоляции транзакционного считываемого и записываемого набора. Эта изоляция обеспечивается посредством приостановки завершения команды в подходящие моменты времени, когда XI являются отложенными; упреждающее исполнение в произвольном порядке разрешено исходя из оптимистического предположения, что отложенные XI относятся к различным адресам и фактически не вызывают транзакционного конфликта. Такое исполнение очень естественно соответствует блокировкам XI против завершения, которые реализованы в современных системах для обеспечения сильной упорядоченности памяти, которой требует архитектура.
Когда L1 240 получает XI, L1 240 обращается к каталогу для проверки допустимости запрошенного посредством XI адреса в L1 240, и если считанный из ТХ бит 248 активен на запрошенной посредством XI строке, и XI не отклонен, LSU 280 инициирует прекращение. Когда строка кэша с активным считанным из ТХ битом 248 является последней по времени использования в L1 240, специальный дополняющий LRU вектор запоминает для каждого из 64 рядов L1 240, что считанная из ТХ строка существует на этом ряду. Поскольку для дополнений LRU не существует какого-либо точного отслеживания адреса, любой неотклоненный XI, который совпадает при поиске с допустимой дополнительной строкой LSU 280, инициирует прекращение. Обеспечение дополнения LRU эффективно повышает ресурсные возможности считывания и ассоциативность от размера L1 до размера L2, при условии, что никакие конфликты с другими ЦП 114 (фиг. 1) против неточного отслеживания дополнения LRU не вызывают прекращений.
Ресурсы сохранения ограничиваются размером кэша сохранений (накопительный кэш обсуждается более подробно ниже) и, таким образом, неявно размером и ассоциативностью L2 268. Не требуется выполнения какого-либо действия дополнения LRU, когда грязные ТХ 252 строки кэша являются последними по времени использования в L1 240.
Кэш сохранений
В современных системах, поскольку L1 240 и L2 268 являются кэшами сквозной записи, каждая команда сохранения вызывает доступ к памяти L3 272; с учетом наличествующих в настоящее время 6 ядер на L3 272 и еще более повышенной производительности каждого ядра, скорость выполнения сохранений для L3 272 (и в меньшей степени для L2 268) становится проблематичной для некоторых рабочих нагрузок. Во избежание задержки в очереди сохранений должен был быть добавлен комплектующий кэш 264 сохранений, который комбинирует сохранения к соседним адресам перед их отправкой в L3 272.
Для производительности транзакционной памяти является приемлемым признание недопустимыми всех ТХ-грязных 252 строк кэша от L1 240 при прекращениях транзакции, поскольку кэш L2 268 является слишком близким (штраф за 7 циклов пропуска L1 240) для возвращения чистых строк. Тем не менее, является недопустимым в плане производительности (и кремниевой области для отслеживания) запись транзакционных сохранений в L2 268 (или еще хуже, в совместно используемом L3 272) до окончания транзакции, а затем признание недопустимыми всех грязных строк кэша L2 268 при прекращении.
Обе проблемы пропускной способности для сохранений и обработки сохранений в транзакционной памяти могут быть решены с помощью комплектующего кэша 264 сохранений. Кэш 232 является кольцевой очередью с 64 записями; каждая запись содержит 128 байтов данных с битами достоверности байтовой точности. В нетранзакционной операции, когда сохранение получено от LSU 280, кэш сохранений проверяет наличие записи для того же самого адреса, и в случае такового, укомплектовывает новое сохранение в существующую запись. Если не существует никакой записи, новая запись записывается в очередь, и если несколько свободных записей подпадают под пороговое значение, самые старые записи записываются обратно в кэши L2 268 и L3 272.
Когда начинается новая наиболее удаленная транзакция, все существующие записи в кэше сохранений отмечаются как закрытые таким образом, что никакие новые сохранения не могут быть в них укомплектованы, и запускается вытеснение этих записей в L2 268 и L3 272. Начиная с этой точки, выходящим из LSU 280 STQ 260 транзакционным сохранениям выделяются новые записи или они укомплектовываются в существующие транзакционные записи. Обратная запись таких сохранений в L2 268 и L3 272 является заблокированной до тех пор, пока транзакция не заканчивается успешно; в этой точке последующие (пост-транзакционные) сохранения могут продолжать укомплектование в существующие записи, пока следующая транзакция вновь не закрывает эти записи.
Кэш сохранений запрашивается на каждом исключающем или понижающем XI, и вызывает отклонение XI, если этот XI сравнивается с любой активной записью. Если ядро не завершает других команд, непрерывно отклоняя XI, для предотвращения зависаний транзакция прекращается по достижении заданного порога.
LSU 280 запрашивает прекращение транзакции при переполнении кэша сохранений.
LSU 280 обнаруживает это условие при своей попытке отправить новое сохранение, которое не может влиться в существующую запись, и весь кэш сохранений заполнен сохранениями от текущей транзакции. Кэшем сохранений управляют как подмножеством L2 268: в то время как транзакционно грязные строки могут быть вытеснены из L1 240, они должны оставаться резидентными в L2 268 на всем протяжении транзакции. Максимальный ресурс для сохранений, таким образом, ограничивается размером 64 х 128 байтов кэша сохранений; он также ограничивается ассоциативностью L2 268. Поскольку L2 268 является 8-канально ассоциативным и имеет 512 рядов, это является обычно достаточно большим для предотвращения прекращений транзакций.
Если транзакция прекращается, кэш сохранений уведомляется, и все содержащие транзакционные данные записи признаются недопустимыми. Кэш сохранений также имеет по метке на двойное слово (8 байтов), указывающей на то, что запись была записана посредством команды NTSTG - такие двойные слова остаются допустимыми после прекращения транзакции.
Реализуемые милликодом функции
Традиционно, процессоры мэйнфреймного сервера IBM содержат уровень встроенного программного обеспечения, называемый милликодом, который выполняет комплексные функции, такие как некоторые выполнения команд CISC, обработка прерываний, синхронизация системы и RAS. Милликод включает в себя машинно-зависимые команды, а также команды архитектуры системы команд (ISA), которые выбираются и выполняются из памяти подобно командам прикладных программ и операционной системы (OS). Встроенное программное обеспечение находится в ограниченной области оперативной памяти, к которой не могут получать доступ потребительские программы. Когда аппаратные средства обнаруживают ситуацию, которая должна вызывать милликод, устройство 204 выборки команд переключается в «режим милликода», и начинает выбирать в соответствующей ячейке памяти в области памяти милликода. Милликод может быть выбран и выполнен таким же образом, как и команды архитектуры системы команд (ISA), и может включать в себя команды ISA.
В том, что касается транзакционной памяти, милликод вовлечен в различные сложные ситуации. Каждое прекращение транзакции вызывает специальную подпрограмму милликода для выполнения необходимых для прекращения операций. Милликод прекращения транзакции запускается посредством считывания регистров особого назначения (SPR), содержащих аппаратную внутреннюю причину прекращения, причины возможного исключения и адрес прекращенной команды, которые параметры милликод затем использует для сохранения TDB, если таковой задан. Текст команды TBEGIN загружается от SPR для получения шаблона хранения GR, который необходим для распознавания милликодом подлежащего восстановлению GR 238.
ЦП 114 (фиг. 2) поддерживает специфичную для милликода команду для считывания из резервной копии GR 224 и для копирования их в главный GR 228. Адрес команды TBEGIN также загружается из SPR для настройки нового адреса команды в PSW для продолжения выполнения после TBEGIN, как только подпрограмма прекращения милликода заканчивается. Этот PSW может позже быть сохранен как программно-старый PSW в случае, если прекращение работы вызывается нефильтрованным прерыванием программы.
Команда TABORT может быть реализована в милликоде; когда IDU 208 декодирует TABORT, он дает устройству выборки команд команду переходить в TABORT милликод, от которого милликод переходит в общую подпрограмму прекращения.
Команда извлечения глубины вложения транзакции (ETND) также может быть милликодирована, поскольку это не является критичным для производительности; милликод загружает текущую глубину вложения из регистра специального оборудования и размещает его в GR 228. Команда РРА милликодируется; посредством этого осуществляется оптимальная задержка на основании текущего отсчета прекращений, поставляемого программным обеспечением, таким как операнд к РРА, а также на основании внутреннего состояния другого аппаратного оборудования.
Для ограниченных транзакций милликод может отслеживать число прекращений. Счетчик сбрасывается к 0 при успешном, завершении TEND, или если происходит прерывание в OS (поскольку не является известным, если или когда OS возвратится к программе). В зависимости от текущего отсчета прекращений милликод может вызывать определенные механизмы для повышения вероятности успеха последующего повторного выполнения транзакции. Механизмы включают в себя, например, последовательное увеличение случайных задержек между повторными выполнениями и уменьшение объема упреждающего выполнения для предотвращения появления прекращений, вызванных упреждающими доступами к данным, которые транзакция фактически не использует. Как последнее средство, милликод может оповещать другие ЦП 114 (фиг. 2) для остановки всех конфликтующих действий, и предприятия повторного выполнения локальной транзакции до разблокирования других ЦП 114 для продолжения нормальной обработки. Множественные ЦП 114 должны быть скоординированы таким образом, что они не вызывают взаимоблокировки, поэтому требуется некоторое преобразование в последовательную форму между реализациями милликода на различных ЦП 114.
Фиг. 4 показывает компьютерную систему 300 согласно варианту осуществления. Система на фиг. 4 выполнена для реализации признаков, обсуждаемых в связи с фиг. 1-3 и 5-18. Компьютер 300 содержит множественные процессоры, обозначенные как процессор 112а (ЦП 1) и 112b (ЦП 2) (наряду с непоказанными дополнительными процессорами), которые соединены с памятью 310 посредством иерархической подсистемы кэша, причем транзакционные загрузки посредством процессора регистрируются в кэше иерархической подсистемы кэша. Компьютерная система 300, показанная на фиг. 4, имеет те же самые элементы, что и компьютерная система 100, показанная на фиг. 1, и те же самые ссылочные обозначения, но не все элементы на фиг. 1 показаны на фиг. 4.
Компьютерная система 300 может управлять запросом, например прерыванием, поставляемым одному или нескольким процессорам, которые доступны для обработки транзакций или выполняют их в настоящее время. В одном из примеров запрашивающий процессор (например, ЦП 1 (112а)) может выбрать приемный/удаленный процессор (например, ЦП 2 (112b)), и отправить запрос к выбранному удаленному процессору. В одном из примеров компьютерная система является системой или окружением выполнения транзакции (ТХ), например, включает в себя ЦП или процессор, способный к выполнению транзакции. Каждая транзакция показана соответственно как транзакционные команды 320а и 320b, которые выполняются соответственно в процессорах 112а и 112b. Каждый процессор 112а и 112b имеет соответственно свой собственный регистр 334а и 334b.
Каждый кэш данных 118а и 118b может включать в себя соответственно свой собственный кэш F1 и F2. Память компьютера, в общем, представлена памятью 310, которая может включать в себя высокоуровневую кэш-память в ЦП, обозначенных как ТХ ЦП, то есть процессорах 112а и 112b. Каждый процессор 112а и 112b имеет свою собственную таблицу отслеживания взаимного вмешательства локальных транзакций, которые обозначены соответственно как таблицы 1350а и 1350b. Таблицы 1350а и 1350b могут быть соответственно сохранены в кэше 118а, 118b данных, регистрах 334а, 334b и/или в памяти 310. Память 310 может также включать в себя транзакционный диагностический блок 350 для хранения диагностической информации по транзакциям, которая может включать в себя информацию по совмещению транзакций (наряду со статистикой), сохраняемую в таблицах 1350а и 1350b, как здесь далее рассмотрено.
Компьютерная система 300 является представлением транзакционного (ТХ) окружения, которое отправляет, получает и обрабатывает как запросы, так и ответы согласно вариантам осуществления. Следует обратить внимание на то, что представлены различные примеры, в которых процессор 112а (ЦП 1) показан как запрашивающий процессор, который генерирует и отправляет запрос к процессору 112b (ЦП 2), который показан как приемный/удаленный процессор, получающий запрос. Подразумевается, что такое обозначение служит разъяснительным целям, поскольку любой процессор способен отправлять и получать запросы на данные, как это понятно специалистам в данной области техники.
Фиг. 5 показывает вариант протокольного запроса и ответа. Протокольный запрос может быть рассмотрен как мэйнфреймовый многопроцессорный протокол, и протокол может быть реализован посредством межсоединения на основе шины или коммутатора. Протокол может быть реализован в виде полностью параллельной передачи сигналов (слежения за шиной), последовательных пакетов или комбинации этих способов.
В качестве примера, запрос 505 на данные может быть отправлен от ЦП 1 (112а) к ЦП 2 (112b). Запрос 505 включает в себя поле 506 типа, которое сообщает, какой запрос отправляется (например, совместно используемое считывание или исключительное считывание или, считывание по принадлежности - запрос согласно известному согласующему протоколу MESI, или протокольные запросы согласно другим таким протоколам), и поле 507 метки, которое идентифицирует конкретный процессор (например, ЦП 1), который отправляет запрос и, опционально, приемный процессор, например ЦП 2, к которому запрос отправляется и, опционально, если могут быть одновременно обработаны множественные запросы, специальный идентификатор запроса для однозначной идентификации каждого запроса. Запрос 505 также включает в себя поле 508 доступа, которое определяет тип доступа, требуемого запрашивающим процессором (ЦП 1), и поле 509 адреса. Поле 509 адреса идентифицирует адрес памяти запрашиваемых строки кэша или слова памяти. Протокольный запрос 505 может включать в себя поле 510 исправления ошибок, которое содержит используемый код обнаружения и/или исправления ошибок, например контроль циклическим избыточным кодом (CRC), биты четности или ЕСС (код исправления ошибок).
Ответ 515 может быть передан обратно от приемного процессора (ЦП 2) к запрашивающему процессору (ЦП 1). Ответ 515 включает в себя поле 516 типа, указывающее на тип ответа, такого как ответ считывания (READRESPONSE) и поле 517 метки. Поле 517 метки может быть представлено той же самой меткой, что и поле 507 метки из исходного запроса 505 и/или поле 517 метки может включать в себя требуемый адрес памяти строки кэша. Ответ 515 включает в себя поле 518 данных, которые являются запрошенными данными, которые были запрошены запрашивающим процессором (ЦП 1). Некоторые протокольные ответы могут не включать в себя передачу данных (например, в ответах на протокольные запросы на повышение уровня принадлежности от совместно используемой до исключительной принадлежности для строки) и могут включать в себя только подтверждение о выполнении обработки. Поле 519 исправления ошибок включается в ответ 515.
В некоторых вариантах осуществления передача сигналов для протокольных запросов может осуществляться параллельно по нескольким разрядным линиям, и любым неиспользованным полям, которые могут соответствовать не имеющим никакого заданного протоколом значения строкам, присваивается значение по умолчанию или, в противном случае, они не считаются частью протокольного сообщения. В некоторых вариантах осуществления протокольный запрос может быть передан во множественных «биениях», например в последовательных группах битов, которые в их совокупности представляют собой протокольное сообщение. Во все же других вариантах осуществления протокольные запросы могут быть переданы побитно. В переданных во множественных биениях или последовательно протоколах некоторые сообщения могут состоять из большего количества циклов передачи сигналов по шине, чем другие протокольные запросы.
Фиг. 6 показывает другой вариант протокольного запроса. Многие протоколы получают исключительный доступ посредством запросов RFO (считывание по принадлежности) или исключительного считывания к операциям записи, в то время как некоторые другие протоколы могут записывать непосредственно (ограниченно). В качестве примера, типовой запрос 605 на запись данных может быть отправлен от ЦП 1 (112а) к ЦП 2 (112b). Запрос 605 включает в себя поле 506 типа, которое идентифицирует тип отправленного запроса (например, на запись), и поле 507 метки, которое идентифицирует конкретный процессор (например, ЦП 1), который отправляет запрос на запись, и опционально, приемный процессор ( например, ЦП 2), к которому запрос отправляется, а также номер запроса. Запрос 605 также включает в себя поле 504 данных, которое передает записанные запрашивающим процессором (ЦП 1) данные, и поле 509 адреса. Поле адреса 509 идентифицирует адрес памяти подлежащих записывания в них строки кэша или строки адреса. Протокольный запрос 605 может включать в себя поле 510 исправления ошибок, которое содержит используемый код обнаружения и/или исправления ошибок, например контроль циклическим избыточным кодом (CRC), биты четности или ЕСС (код исправления ошибок).
В ответ на запрос на запись обычно нет никакого ответа, поскольку не является необходимым получение данных для исключительного доступа до выполнения записи.
Фиг. 7 является блок-схемой 700 создания протокольного запроса посредством процессора (например, ЦП 1 (112а)), который делает запрос на данные согласно варианту осуществления. Процессор (например, ЦП 1) имеет запрос на данные памяти в блоке 705. Процессор (например, ЦП 1 (112а)) проверяет в блоке 710 наличие запрашиваемых данных в своем собственном локальном кэше (например, кэше L1 в кэше 118а данных). Когда данные являются доступными в собственном локальном кэше процессора, выполнение переходит к блоку 735. Когда данные не являются доступными в локальных кэшах процессора (ЦП 1), процессор в блоке 715 генерирует XI запрос (перекрестный запрос) для запроса требуемых данных от других процессоров (таких как ЦП 2 (112b)). Запрашивающий процессор (ЦП 1) отправляет этот XI запрос на данные к приемному процессору (ЦП 2) через межсоединение 122 в блоке 720, и запрашивающий процессор (ЦП 1) получает XI ответ с (запрошенными) данными от приемного процессора (ЦП 2) в блоке 725. Запрашивающий процессор (ЦП 1) размещает в блоке 730 данные в своих локальных кэшах (например, кэшах L1, L2) в кэше 118а данных. Запрашивающий процессор (ЦП 1) получает в блоке 735 данные из своего локального кэша 118а через кэш 116а команд. Кэш 116а команд запрашивающего процессора предоставляет данные к контурам ЦП 1 для обработки в блоке 740.
В одном варианте осуществления и согласно общему протоколу кэша (например, известному протоколу MESI), когда процессор получает доступ к данным для считывания, и данные не является доступными, генерируется XI запрос для совместно используемого считывания, причем данные получают способом совместного использования таким образом, что множественные ЦП 112а, 112b могут иметь копию данных в кэше, и причем каждый ЦП может обрабатывать соответствующий данным доступ для считывания из памяти. Полученные данные размещаются в кэше и отмечаются для совместного доступа, а процессор может осуществлять доступ для считывания из копии, реагируя на операции считывания из памяти. Когда процессор пытается получить доступ к данным для записи, и данные не являются доступными в исключительном состоянии, генерируется XI запрос для исключительного считывания, причем данные получают исключительным способом таким образом, что только единственный ЦП (например, ЦП 112а) может иметь копию данных в кэше. Полученные данные размещаются в кэше и отмечаются для исключительного доступа, а процессор может обновлять копию, реагируя на операции записи в память. В одном варианте осуществления, когда данные присутствуют в режиме совместного использования, и получен доступ для записи, генерируется XI запрос на исключительное считывание. По меньшей мере в одном варианте осуществления это обозначается как уникальный запрос на исключительное считывание, причем в качестве части ответа не получают каких-либо данных. В одном варианте осуществления, когда ответ был получен, данные кэша отмечаются для исключительного доступа.
Фиг. 8 показывает типовую блок-схему 800 обработки запроса посредством приемного/удаленного процессора (например, ЦП 2 (112b)), который получает запрос и отправляет ответ согласно варианту осуществления.
Удаленный процессор (ЦП 2) получает XI запрос на данные от запрашивающего процессора (ЦП 1) в блоке 805. В блоке 810 удаленный процессор (ЦП 2) проверяет, было ли обнаружено взаимное вмешательство, посредством проверки того, обрабатывает ли удаленный процессор транзакцию, которая в настоящее время нуждается в запрошенных данных (в локальном кэше удаленного процессора). Когда в блоке 810 удаленный процессор (ЦП 2 (112b)) выявляет, что удаленный процессор в настоящее время использует данные, запрошенные запрашивающим процессором (ЦП 1 (112а)), удаленный процессор задает наличие (YES) обнаружения взаимного вмешательства, и удаленный процессор (ЦП 2) в блоке 815 прекращает происходящую на удаленном процессоре (ЦП 2) локальную транзакцию. Как только локальная транзакция на удаленном процессоре (ЦП 2) прекращается, удаленный процессор передает данные с ответом считывания (READRESPONSE) к запрашивающему процессору (ЦП 1) в блоке 820. Удаленный процессор (ЦП 2) изменяет состояние данных и, опционально, при необходимости, производит очистку данных из своих локальных кэшей в блоке 825. В одном варианте осуществления изменение состояния кэша может включать в себя разблокирование данных по меньшей мере из одного набора в числе наборов значений для считывания или записи, когда транзакция была прекращена. В одном варианте осуществления изменение состояния кэша может включать в себя изменение состояния строки кэша в каталоге кэша, например присваивание состоянию значения из числа совместно используемая, исключительная, недопустимая, и т.д., согласно протоколу кэша, такому как известный протокол MESI. Удаленный процессор (ЦП 1) инициирует обработку сбоя транзакции в блоке 830, и выполнение заканчивается. Когда удаленный процессор в блоке 810 (ЦП 2 (112b)) выявляет, что удаленный процессор в настоящее время не использует запрошенные посредством запрашивающего процессора (ЦП 1 (112а)) данные, удаленный процессор задает отсутствие (NO) обнаружения взаимного вмешательства, и удаленный процессор (ЦП 2) в блоке 835 передает данные с ответом считывания (READRESPONSE). Удаленный процессор (ЦП 2) изменяет состояние данных и, опционально, при необходимости, производит очистку данных из своих локальных кэшей в блоке 840, и выполнение заканчивается.
Фиг. 9 является блок-схемой 900, показывающей обработку транзакции посредством процессора согласно варианту осуществления. В блоке 905 транзакция начинает выполняться на процессоре (например, ЦП 1 или ЦП 2). На фиг. 9 следует обратить внимание на то, что каждый процессор (ЦП 1 и ЦП 2) может выполнять эти действия, то есть транзакции могут быть обработаны посредством обоих 112а, 112b и т.д. Процессор выполняет команды в пределах транзакции в блоке 910 (например, как рассмотрено на фиг. 7). Процессор выполняет в блоке 915 действия протокола, реагируя на транзакционные команды. Процессор проверяет в блоке 920 наличие взаимного вмешательства (с использованием данных), которое требует от процессора прекращения своей транзакции. Когда процессор выявляет взаимное вмешательство как обнаруженное (YES), процессор в блоке 925 прекращает свою собственную транзакцию (на данных), а выполнение переходит к блоку 935. Когда процессор выявляет взаимное вмешательство как необнаруженное (NO), процессор в блоке 930 завершает свою транзакцию (выполнение ее команд). Процессор записывает в блоке 935 информацию о транзакции (такую как транзакционный диагностический блок (TBD)) в регистре.
Согласно вариантам осуществления согласующий протокол расширяется для включения в него дополнительной информации относительно состояния транзакции. Фиг. 10 показывает протокольный запрос 505 и новый протокольный ответ 1005 согласно вариантам осуществления. Как показано на фиг. 10, некоторые поля 505 запроса являются идентичными полям, рассмотренным на фиг. 5. Как отмечено выше, запрос 505 включает в себя поле 506 типа, которое идентифицирует тип отправленного запроса (например, READ), и поле 507 метки, которое идентифицирует конкретный процессор (например, ЦП 1), и опционально, приемный/удаленный процессор, например ЦП 2, к которому запрос отправляется, а также номер запроса. Запрос 505 также включает в себя поле 508 доступа, которое сообщает тип доступа, требуемого запрашивающим процессором (ЦП 1), и поле 509 адреса, которое сообщает адрес памяти запрашиваемых строки кэша или строки адреса. Протокольный запрос 505 может включать в себя поле 510 исправления ошибок, которое сообщает используемый код обнаружения и/или исправления ошибок, например контроль циклическим избыточным кодом (CRC).
Новый ответ 1005, наряду с дополнительным полем 1010 состояния прекращения транзакции, включает в себя поля 515 ответа (на фиг. 5). Ответ 1005 может быть передан обратно от приемного/удаленного процессора (ЦП 2) к запрашивающему процессору (ЦП 1). Ответ 515 включает в себя поле 516 типа, указывающее на тип ответа, такой как ответ считывания (READRESPONSE), и поле 517 метки (которое может быть представлено той же самой меткой, что и поле метки 507 исходного запроса 505), указывающее запрашиваемый адрес памяти строки кэша.
Ответ 515 включает в себя поле 518 данных, которые являются запрошенными данными, которые были запрошены запрашивающим процессором (ЦП 1). Если данные не были переданы с протокольным ответом, то поле данных 518 является пустым или не существует. В ответ 1005 включено поле 519 обнаружения/исправления ошибок.
Кроме того, новый протокольный ответ 1005 (отправляемый удаленным процессором ЦП 2 в запрашивающий процессор ЦП 1) имеет поле 1010 состояния прекращения транзакции. Поле 1010 состояния прекращения транзакции включает в себя один или несколько из следующих элементов информации относительно транзакции, ранее выполнявшейся на удаленном/приемном процессоре (ЦП 2) прежде, чем быть прекращенной:
1) Вызвал или не вызвал запрос 505 (от запрашивающего процессора (ЦП 1) откат (то есть, прекращение),
2) Приоритет транзакции, которая выполнялась на удаленном/приемном процессоре (ЦП 2) прежде, чем быть прекращенной,
3) Сколько команд, операций с памятью и/или других показателей проделанной работы было выполнено транзакцией, ранее выполнявшейся на удаленном/приемном процессоре ЦП 2) прежде, чем транзакция была прекращена,
4) Идентификация транзакции (например, маркер, адрес TBEGIN и/или другие средства идентификации прекращенной транзакции) ранее выполнявшейся на удаленном процессоре (ЦП 2).
Кроме того, поле 1010 состояния прекращения транзакции сообщает о том, какие данные были получены транзакцией (ранее выполнявшейся на удаленном/приемном процессоре), которая должна была быть прекращена, сообщает адрес транзакции и сообщает цену прекращения транзакции (которая может составлять 3 или 20000 тактовых циклов работы).
Когда процессор (например, приемный процессор ЦП 2 в типовых сценариях) находится в процессе транзакционного выполнения, согласующий запрос может принудить процесс транзакционного выполнения прекратиться, например поскольку данные являются частью набора значений для считывания или записи транзакции, и обнаруживается конфликт (то есть, взаимное вмешательство).
Согласно варианту осуществления фиг. 11 показывает запрос 605 (на запись) на фиг. 6 для записи данных (отправленный от запрашивающего процессора ЦП 1 (112а) к приемному/удаленному процессору ЦП 2 (112b)), и новый ответ 1105, отправленный обратно к запрашивающему процессору ЦП 1 (112а) от удаленного процессора ЦП 2 (112b). Фиг. 11 представляет пример протокольного запроса и ответа, который добавляет информацию о транзакции в ответе согласно варианту осуществления посредством введения нового протокольного ответа для транзакции, которая ранее не требовала протокольного ответа, с целью передачи информации к инициатору запроса о взаимном вмешательстве транзакций/прекращении. По меньшей мере в одном варианте осуществления протокольного ответа, который передается с единственной целью предоставления состояния прекращения транзакции, ответ является опциональным, и может быть подавлен в некоторых режимах, в ответ на биты конфигурации, в ответ на перегруженность шины и/или по другим причинам. В таком сценарии, при неполучении какого-либо ответа, не сообщается ни о каком состоянии прекращения транзакции, соответствующем запросу, для которого не было получено никакого ответа. По меньшей мере в одном варианте осуществления можно сообщать об отсутствии одного или нескольких ответов. Как отмечено выше, запрос 605 включает в себя поле 506 типа, которое сообщает о том, какой тип запроса отправляется (например, на запись), и поле 507 метки, которое идентифицирует конкретный процессор (например, ЦП 1), который отправляет запрос на запись (и приемный процессор, например ЦП 2, к которому отправляется запрос). Запрос 605 также включает в себя поле 508 доступа, которое сообщает тип доступа, запрашиваемого запрашивающим процессором (ЦП 1), и поле 509 адреса. Поле 509 адреса сообщает адрес памяти подлежащих записыванию в них строки кэша или строки адреса. Протокольный запрос 605 может включать в себя поле 510 обнаружения и/или исправления ошибок, которое содержит код исправления и/или обнаружения ошибок, такой как биты четности, ЕСС или контроль циклическим избыточным кодом (CRC).
В ответ на запрос 605 на запись новый ответ 1105 (к запросу на запись) теперь включает в себя рассматриваемое в настоящем документе поле 1010 состояния прекращения транзакции. Новый ответ 1105 включает в себя поля 1005 ответа (на фиг. 10). Ответ 1105 может быть передан обратно от приемного/удаленного процессора (ЦП 2) к запрашивающему процессору (ЦП 1). Ответ 1105 включает в себя поле 516 типа, указывающее на тип ответа, такой как ответ записывания (WRITERESPONSE), и поле 517 метки (которое может быть представлено той же самой меткой, что и поле 507 метки исходного запроса 505 для идентификации соответствующего ответу запроса), указывающее запрашиваемый адрес памяти строки кэша. Ответ 515 может включать в себя поле 518 данных, которое является запрошенными данными, которые были запрошены запрашивающим процессором (ЦП 1). Поскольку никакие данные не происходят из (локального) кэша приемного/удаленного процессора (ЦП 2), поле данных 518 является пустым. В ответ 1005 включено поле 519 исправления ошибок.
Как рассматривается в настоящем документе, поле 1010 состояния прекращения транзакции предоставляет состояние транзакции (ранее выполнявшийся на приемном/удаленном процессоре (ЦП 2)), которую потребовалось прекратить вследствие запроса 605 на запись (от запрашивающего процессора (ЦП 1)).
В то время как улучшения протокола согласно настоящему раскрытию были описаны для одного типового варианта осуществления в связи с добавлением поля протокола, соответствующего состоянию прекращения транзакции, а также ассоциированной информации к существующему ответу считывания к запросу на считывание, и в другом типовом варианте осуществления в связи с добавлением протокольного ответа, соответствующего протокольному запросу на запись, не имеющему протокольного ответа в соответствии с известным уровнем техники, с целью передачи по меньшей мере одного поля протокола, соответствующего состоянию прекращения транзакции, а также ассоциированной информации и идентификации соответствующего запроса на запись; специалисты в данной области техники могут приложить содержащиеся в настоящем документе принципы к другим XI форматам, протокольным форматам, типам запросов, согласующим протоколам и т.д.
Согласно варианту осуществления фиг. 12 является блок-схемой 1200, показывающей обработку согласующего запроса, например посредством приемного/удаленного процессора ЦП 2 (112b), который получает запрос от запрашивающего процессора ЦП 1 (112а). Фиг. 12 включает в себя блоки на фиг. 8, наряду с новыми (измененными) блоками 1205 и 1210, которые содержат передачу состояния прекращения транзакции (в поле 1010 прекращения транзакции) в качестве части протокольных ответов.
На фиг. 12 представлена обработка запроса посредством приемного/удаленного процессора (например, ЦП 2 (112b)), получающего запрос согласно варианту осуществления. Удаленный процессор (ЦП 2) получает XI запрос (например, запрос 505 и/или запрос 605) на данные от запрашивающего процессора (ЦП 1) в блоке 805. В блоке 810 удаленный процессор (ЦП 2) проверяет, было ли обнаружено взаимное вмешательство, посредством проверки того, обрабатывает ли удаленный процессор транзакцию, которая ссылается на данные способом, несовместимым с полученным запросом, например запрос 505 и 605. Например, в одном образцовом варианте осуществления, запрос на совместно используемое считывание является совместимым со ссылкой на данные в транзакционном наборе значений для считывания, а запрос на запись не является. Кроме того, исключительное считывание, повышение уровня считывания (то есть, изменение от совместно используемого до исключительного), или запрос на запись не являются совместимыми с теми же самыми данными, на которые имеется отсылка в транзакционном наборе значений либо для считывания, либо для записи. Когда в блоке 810 удаленный процессор (ЦП 2 (112b)) выявляет, что удаленный процессор (как таковой) в настоящее время использует данные, запрошенные запрашивающим процессором (ЦП 1 (112а)), удаленный процессор задает наличие (YES) обнаружения взаимного вмешательства, и удаленный процессор (ЦП 2) в блоке 815 прекращает происходящую в удаленном процессоре (ЦП 2) локальную транзакцию. Как только локальная транзакция на удаленном процессоре (ЦП 2) прекращается, удаленный процессор, наряду с полем 1010 состояния транзакции (которое регистрирует, что запрос принудил транзакцию (ранее выполнявшуюся) прекратиться на удаленном/приемном процессоре (ЦП 2), передает данные с ответом считывания (READRESPONSE) к запрашивающему процессору (ЦП 1) с целью выполнения запроса в блоке 1205. В другом варианте осуществления удаленный процессор может подтверждать получение запроса на запись посредством ответа 1105 записи. В современных системах отсутствует какое-либо поле 1010 состояния транзакции в ответе (RESPONSE), отправляемом от удаленного ЦП 2 (который ранее выполнял его собственную, теперь прекращенную транзакцию) обратно к запрашивающему ЦП 1 (который отправляет запрос 505 и/или 605). Удаленный процессор (ЦП 2) изменяет состояние данных и, опционально, при необходимости, производит очистку данных из своих локальных кэшей в блоке 825. Удаленный процессор (ЦП 1) инициирует обработку сбоя транзакции в блоке 830, и выполнение заканчивается. Когда удаленный процессор (ЦП 2 (112b)) в блоке 810 выявляет, что удаленный процессор в настоящее время не использует запрошенные посредством запрашивающего процессора (ЦП 1 (112а)) данные, удаленный процессор задает отсутствие (NO) обнаружения взаимного вмешательства, и удаленный процессор (ЦП 2) в блоке 1210, наряду с полем 1010 состояния транзакции (которое указывает, что запрос не принудил транзакцию прекратиться) передает данные с ответом считывания (READRESPONSE). Удаленный процессор (ЦП 2) изменяет состояние данных и, опционально, при необходимости, производит очистку данных из своих локальных кэшей в блоке 840, и выполнение заканчивается.
Фиг. 13 является блок-схемой 1300, показывающей протокольный запрос на получение данных и обработку посредством запрашивающего процессора (ЦП 1 (112а)) согласно варианту осуществления. Фиг. 13 включает в себя блоки, рассмотренные выше на фиг. 7, а рассмотрение по фиг. 7 не повторяется. Кроме того, блок-схема 1300 включает в себя новые блоки 1305 и 1310. Например, запрашивающий процессор (ЦП 1), наряду с новым полем 1010 состояния прекращения транзакции в блоке 1305, получает XI ответ с данными от удаленного процессора (ЦП 2) (блок 725). Запрашивающий процессор (ЦП 1) размещает данные в локальных кэшах (таких как L1 и/или кэши L2) в блоке 730. В блоке 1310 запрашивающий процессор (ЦП 1) добавляет полученное состояние (например, информацию в поле 1010 состояния транзакции) к таблице 1350а отслеживания взаимного вмешательства локальных транзакций в кэше данных 118а (и/или памяти 310). Таблица 1350а отслеживания взаимного вмешательства локальных транзакций может быть местом хранения, которое отслеживает взаимное вмешательство, когда запрашивающий процессор (ЦП 1) вызывает взаимное вмешательство (приводящее к прекращению транзакции на удаленном процессоре (ЦП 2)), и таблица 1350а отслеживания взаимного вмешательства локальных транзакций может включать в себя журнал для этой информации. (Накопительная) таблица 1350а локального отслеживания взаимного вмешательства транзакций включает в себя статистику увеличения отсчета и текущее состояние транзакции. Статистика увеличения отсчета возрастает для каждого прекращения транзакции (сообщенного обратно приемному процессору (ЦП 1), и статистика увеличения отсчета может быть разделена на совместно используемые/исключительные (R/W) запросы и агрегированные запросы. Накопительная таблица 1350а локального отслеживания взаимного вмешательства транзакций может включать в себя счетчик, увеличение отсчета которого возрастает для каждого прекращения транзакции, вызванного запрашивающим процессором (ЦП 1) и для каждого случая отсутствия прекращения транзакции на запрашивающем процессоре (ЦП 1). В некоторых вариантах осуществления состояние прекращения транзакции, полученное в связи с блоком 1310, также может быть агрегировано в устройстве мониторинга производительности, в динамическом измерительном устройстве и/или в другом логическом устройстве мониторинга производительности с целью обеспечения доступности информации для средств динамической оптимизации, динамических компиляторов (JIT) или для регулирования производительности посредством программистов. Информация может быть зарегистрирована посредством записывания ее в системе хранения, в направленных на мониторинг производительности структурах и/или посредством активации оповещений, например основанных на событиях PMU ответвлений согласно Power ISA™ или исключениях. Отчет может включать в себя характер взаимного вмешательства, идентификацию подвергшейся вмешательству и/или создавшей вмешательство транзакции, идентификаторы процессоров, являющиеся предметами такого взаимного вмешательства адреса и т.д.
Как рассматривается в настоящем документе, согласующие протоколы используют различные биты - биты адреса, данных, а также биты состояния и управления. Эти данные используются для выдачи запроса на данные и для указание на их принадлежность (например, совместно используемые, исключительные), а также на состояние (например, грязные, чистые). Дополнительно добавляются один или несколько битов (для поля 1010 состояния прекращения транзакции) для указания на то, что запрос принудил транзакцию прекратиться и/или мог принудить транзакцию прекратиться. Например, бит состояния (поле 1010 состояния прекращения транзакции) указывает на то, что запрошенные данные вызвали конфликт транзакционного выполнения, когда данные были переданы удаленным процессором (ЦП 1). Как отмечено, ответ на запрос может возвратиться с указателем на то, что транзакция находится в процессе выполнения и, что запрос принудил транзакцию прекратиться.
В одном варианте осуществления в поле 1010 состояния прекращения транзакции передается дополнительный показатель, такой как число команд в прекращенной транзакции. В одном варианте осуществления указатели используются для выявления задержки, например относительно перезапуска транзакции в случае, когда побеждающая транзакция позже становится прекращенной, и перезапускается для предотвращения сценариев динамической взаимоблокировки. Запрашивающий процессор (ЦП 1) может также дросселировать (уменьшать) скорость подачи его запросов в ответ на прекращение слишком многих удаленных транзакций для повышения полной пропускной способности системы, когда запрашивающий процессор (ЦП 1) выявляет посредством проверки локального поля 1010 состояния прекращения транзакции, что запрашивающий процессор вызывает слишком много (например, предопределенное число) прекращений транзакций в удаленном/приемном процессоре (ЦП 2).
В еще одном варианте осуществления такие оповещения (в поле 1010 состояния прекращения транзакции) укомплектовываются в журналы и/или регистрируются с помощью механизма оповещения (например, исключительного состояния) в компоненте динамической повторной оптимизации; компонент динамической повторной оптимизации может динамически повторно оптимизировать код для уменьшения взаимного вмешательства и/или генерировать дополнительный код для использования блокировок вместо транзакций.
Далее, блоки на фиг. 9 включены в фиг. 14, но их рассмотрение не повторяется. Фиг. 14 также включает в себя модификацию по отношению к фиг. 9. Фиг. 14 является блок-схемой 1400, показывающей обработку транзакции посредством процессора согласно варианту осуществления. Можно предположить, что процессор является запрашивающим процессором (ЦП 1). Фиг. 14, наряду с блоком 1405, включает в себя блоки на фиг. 9. В блоке 1405 запрашивающий процессор (ЦП 1) записывает информацию о транзакции (такую как транзакционный диагностический блок (TBD)), включая сюда статистику транзакционного взаимного вмешательства (полученную из нового поля 1010 состояния прекращения транзакции и сохраненную в накопительной таблице 1350а локального отслеживания взаимного вмешательства транзакций) в регистре 334, кэше 118а и/или памяти 310 в блоке 1405. В одном варианте осуществления, когда транзакция завершается, транзакция может включать в себя указатель того, принудила ли она прекратиться одну или несколько транзакций, как часть кода результата, например регистра результата, регистра условия результата и т.д. (например, в регистрах 334а, 334b). В одном варианте осуществления, когда транзакция присваивает значение состоянию результата в одном или нескольких регистрах (например, регистрах 334а, 334b) и/или ячейках памяти, один или несколько регистров (например, в регистрах 334а, 334b) и/или ячейки памяти (например, в памяти 310, кэшах 118а, 118b) могут включать в себя число испытавших взаимное вмешательство транзакций, наряду с прекращенными для предоставления данных для транзакции, характер взаимного вмешательства (запрос на считывание с записываемым набором или запрос на запись либо со считываемым, либо с записываемым набором и т.д.). В одном варианте осуществления таким образом сохраненная информация может включать в себя специальную информацию по каждой из транзакций, включая сюда способ идентификации процессора, на котором произошло взаимное вмешательство, прекращенную транзакцию (например посредством указания адреса начала транзакции XBEGIN или TBEGIN, маркер, идентификатор транзакции и т.д.), показатель проделанной работы, выполненной данной транзакцией до ее прекращения и т.д. В одном варианте осуществления, когда современный транзакционный диагностический блок расширяется согласно настоящему раскрытию для наделения его дополнительными полями, соответствующими взаимному вмешательству и состоянию прекращения транзакции, сохраненная в одной или нескольких ячейках памяти информация соответствует ячейкам памяти транзакционного диагностического блока (TDB) в соответствии, например, с Z-архитектурой (включенной в настоящий документ посредством отсылки), и полям транзакционного диагностического блока согласно настоящему раскрытию, причем поля соответствуют информации, переданной индивидуально посредством по-новому введенных полей протокола и/или посредством агрегированной информации от нескольких таких полей. В другом варианте осуществления сохраненная в регистрах и/или ячейках памяти информация предоставляется в качестве отличной, отдельной и независимой от современного TDB.
Запрашивающий процессор (ЦП 1) выполнен для предоставления в блоке 1405 программисту статистики взаимного вмешательства посредством устройства мониторинга производительности и/или динамического измерительного устройства, и предоставляет информацию о взаимном вмешательстве встроенному программному обеспечению, милликоду и т.д. В милликоде: код милликода может использовать информацию по статистике взаимного вмешательства для предотвращения динамической взаимоблокировки и/или может использовать информацию по статистике взаимного вмешательства для оптимизации перезапуска транзакции. В приложении: приложение может использовать информацию по статистике взаимного вмешательства для предотвращения динамической взаимоблокировки и оптимизации перезапуска транзакции.
Согласно варианту осуществления типовой код предоставлен ниже в целях объяснения.
Последующий псевдокод (выполняемый на процессорах 112а, 112b) предоставляет один вид оптимизации перезапуска выполняющейся транзакции (или без перекодировки в милликоде, и/или посредством кода, встроенного в приложение, выполняющемся на процессоре) с целью перезапуска транзакции, когда транзакция прекращается и оптимизируется, прежде всего, для предотвращения сценариев динамической взаимоблокировки. Типовой код использует сохраненную в TDB типовым способом информацию, однако специалисты в данной области техники могут использовать информацию, полученную из, в том числе, но не ограничиваясь, ячеек памяти (например, памяти 310), регистров 334а, 334b, кодов состояний и/или устройства мониторинга производительности, динамического измерительного устройства и т.д.:
Согласно типовому коду код перезапуска транзакции включает в себя проверки ее прекращения как таковой и, в свою очередь, вызывания ею прекращения другой транзакции. В одном варианте осуществления возможная динамическая взаимоблокировка диагностируется немедленно. В другом варианте осуществления выполняется тест (не показан) на то, являются ли настоящая транзакция и испытывающая взаимное вмешательство транзакция частями циклического графа взаимного вмешательства (то есть, каждая транзакция либо прямо, либо косвенно прекращает другую транзакцию). В одном варианте осуществления, когда диагностирован взаимный останов, предпринимаются действия для предотвращения взаимного вмешательства. В одном варианте осуществления, когда диагностирован взаимный останов, предпринимаются действия для предотвращения динамической взаимоблокировки. В одном варианте осуществления действия для предотвращения взаимного вмешательства вызываются посредством обращения к функции avoid_livelock ()
(предотвращение_динамической_взаимоблокировки()). В некоторых вариантах осуществления эти действия могут содержать, но не быть этим ограниченными, одну или несколько настоящих транзакций более низкого приоритета; ожидание в течение периода задержки; синхронизацию использования блокировок; и т.д.
В другом типовом варианте осуществления последующий псевдокод предоставляет один вид оптимизации перезапуска выполняющейся транзакции (либо без перекодировки в милликоде, и/или посредством кода, встроенного в приложение, выполняющееся на процессоре) с целью перезапуска транзакции, когда она прекращается и оптимизируется, прежде всего, для предотвращения сценариев динамической взаимоблокировки. Типовой код использует сохраненную в TDB типовым способом информацию, однако специалисты в данной области техники могут использовать информацию, полученную из, в том числе, но не ограничиваясь, ячеек памяти, регистров, кодов состояний и/или устройства мониторинга производительности, динамического измерительного устройства и т.д. В типовом коде транзакция вызывает операции по предотвращению динамической взаимоблокировки, когда это соответствует превышению транзакцией порогового значения для (возможных) взаимных остановов:
Согласно типовому коду код перезапуска транзакции включает в себя проверки ее прекращения как таковой и, в свою очередь, вызывания ею прекращения другой транзакции. В одном варианте осуществления возможная динамическая взаимоблокировка диагностируется немедленно. В другом варианте осуществления выполняется тест (не показан) на то, являются ли настоящая транзакция и испытывающая взаимное вмешательство транзакция частями циклического графа взаимного вмешательства (то есть, каждая транзакция либо прямо, либо косвенно прекращает другую транзакцию). В одном варианте осуществления, когда было диагностировано превышающее пороговое значение число взаимных остановов (взаимный_останов > пороговое значение), предпринимаются действия для предотвращения взаимного вмешательства. В одном варианте осуществления, когда было диагностировано превышающее пороговое значение число взаимных остановов (взаимный_останов > пороговое значение), предпринимаются действия для предотвращения динамической взаимоблокировки. В одном варианте осуществления действия для предотвращения взаимного вмешательства вызываются посредством обращения к функции avoid_livelock () (предотвращение_динамической_взаимоблокировки()). В некоторых вариантах осуществления эти действия могут содержать, но не быть этим ограниченными, одну или несколько настоящих транзакций более низкого приоритета, ожидание в течение периода задержки, синхронизацию использования блокировок, и т.д.
Оптимизация перезапуска (либо без перекодировки в милликоде, либо в приложении):
Согласно типовому коду код перезапуска транзакции включает в себя проверки ее прекращения как таковой и, в свою очередь, вызывания ею прекращения другой транзакции. В одном варианте осуществления возможная динамическая взаимоблокировка диагностируется немедленно. В одном варианте осуществления, когда было диагностировано превышающее пороговое значение число взаимных остановов (взаимный_останов > пороговое значение), выполняется live_lock_loop_detected ()
(оператор_цикла_динамической_взаимоблокировки()) тест, который может получить доступ к дополнительной информации, полученной с помощью ответных сообщений о состоянии прекращения и, опционально, совместно с другими средствами, если настоящая транзакция и испытавшая взаимное вмешательство транзакция являются или, в другом варианте осуществления, могут являться, частями циклического графа взаимного вмешательства (то есть, каждая транзакция либо прямо, либо косвенно прекращает другую транзакцию). В таком случае предпринимаются действия для предотвращения динамической взаимоблокировки. В одном варианте осуществления действия для предотвращения динамической взаимоблокировки вызываются посредством обращения к функции avoid_livelock () (предотвращение_динамической взаимоблокировку)). В некоторых вариантах осуществления эти действия могут содержать, но не быть этим ограниченными, одну или несколько настоящих транзакций более низкого приоритета, ожидание в течение периода задержки, синхронизацию использования блокировок, и т.д.
Согласно варианту осуществления фиг. 15 является блок-схемой 1500, показывающей, как процессор (например, запрашивающий процессор ЦП 1) отвечает на индикацию взаимного вмешательства, например сохраняемую (а также увеличивающуюся/отслеживаемую) в накопительной таблице 1350а локального отслеживания взаимного вмешательства транзакций, получаемую от информации в поле 1010 состояния прекращения транзакции. Запрашивающий процессор (ЦП 1) сообщает о статистике взаимного вмешательства в блоке 1505. Сообщение статистики взаимного вмешательства может включать в себя запись информации о транзакции, как это рассмотрено относительно блока 1405. В блоке 1510 запрашивающий процессор (ЦП 1) выявляет возможность проведения дополнительной синхронизации для предотвращения повторного взаимного вмешательства путем выявления случаев слишком высокой цены взаимного вмешательства. Цена взаимного вмешательства является слишком высокой, когда запрашивающий процессор (ЦП 1) неоднократно прекращает (ту же самую) транзакцию, выполняющуюся на приемном/удаленном процессоре (ЦП 2) предопределенное число раз (например, 4), и/или когда транзакция завершила предопределенное число тактовых циклов (например, 10000 тактовых циклов) команд прежде, чем быть прекращенной.
Когда запрашивающий процессор (ЦП 1) выявляет, что дополнительная синхронизация не является возможной для предотвращения повторного взаимного вмешательства (повторных прекращений транзакции на удаленном процессоре (ЦП 2), вызываемого запросом на данные от запрашивающего процессора (ЦП 1) в блоке 1510, запрашивающий процессор (ЦП 1) в блоке 1515 проверяет возможность повторной оптимизации кода. Когда запрашивающий процессор (ЦП 1) выявляет, что повторная оптимизация является возможной, запрашивающий процессор в блоке 1520 повторно оптимизирует код. Когда запрашивающий процессор (ЦП 1) выявляет, что повторная оптимизация не является возможной, запрашивающий процессор продолжает в блоке 1525 работу с текущим кодом (включая сюда работу с допусками, такими как задержка). Задержка происходит, когда запрашивающий процессор решает ожидать предопределенное количество времени прежде, чем сделать запрос на данные, для предоставления приемному/удаленному процессору (ЦП 2) времени, необходимого для завершения выполнения (без прекращения) транзакции на приемном/удаленном процессоре.
Когда запрашивающий процессор (ЦП 1) в блоке 1510 выявляет, что дополнительная синхронизация является возможной для предотвращения повторного взаимного вмешательства (повторных прекращений транзакции на удаленном процессоре (ЦП 2), вызываемого запросом на данные от запрашивающего процессора (ЦП 1), запрашивающий процессор (ЦП 1) в блоке 1530 использует альтернативную синхронизацию. Запрашивающий процессор (ЦП 1) в блоке 1535 проверяет, например, журнал в накопительной таблице 1350а локального отслеживания взаимного вмешательства транзакций для выявления того, когда повторное взаимное вмешательство (той же самой транзакции (то есть, имеющей тот же самый кэш/адрес памяти) произошло на удаленном/приемном процессоре (ЦП 2). Когда повторное взаимное вмешательство отсутствует, выполнение переходит к блоку 1525. Когда запрашивающий процессор (ЦП 1) выявляет наличие повторного взаимного вмешательства (для той же самой прекращенной транзакции на удаленном/приемном процессоре (ЦП 2)), запрашивающий процессор в блоке 1540 проверяет возможность проведения повторной оптимизации кода. Когда повторная оптимизация является возможной, запрашивающий процессор (ЦП 1) в блоке 1545 повторно оптимизирует код.
Когда запрашивающий процессор (ЦП 1) выявляет, что повторная оптимизация кода не является возможной, запрашивающий процессор (ЦП 1) конфигурируется для постоянного (и/или в течение заданного периода) выбора в блоке 1550 альтернативного способа синхронизации для этой конкретной транзакции (выполняющейся на запрашивающем процессоре (ЦП 1)), запрашивающей данные от приемного/удаленного процессора (ЦП 2).
Согласно варианту осуществления фиг. 16 является блок-схемой 1600, показывающей, как процессор (например, запрашивающий процессор (ЦП 1)) отвечает на индикацию взаимного вмешательства, например, сохраняемую (а также увеличивающуюся/отслеживаемую) в накопительной таблице 1350а локального отслеживания взаимного вмешательства транзакций, получаемую от информации в поле 1010 состояния прекращения транзакции. Фиг. 16 включает в себя блоки на фиг. 15, за исключением того, что блок 1605 заменяет блок 1540. Блоки на фиг. 15 не повторяются.
Когда блок 1535 имеет значение YES, выполнение переходит к блоку 1605 на фиг. 16. На блоке 1605 запрашивающий процессор (ЦП 1) проверяет предпочтительность повторной оптимизации или альтернативной синхронизации. Когда значение в блоке 1605 представлено YES, выполнение переходит к блоку 1545. Когда значение в блоке 1605 представлено NO, выполнение переходит к блоку 1550. В блоке 1540 на фиг. 15, когда повторная оптимизация кода является возможной, повторная оптимизация кода всегда выполняется. В блоке 1605 вычисляется показатель для выявления желательности повторной оптимизации кода или альтернативного способа синхронизации (например, блокировки), и выбор того или другого. Выбор может быть основан, например, на тесте, сравнивающем для выявления желательного способа совокупную цену использования альтернативного способа синхронизации с ценой использования повторно оптимизированного кода, добавленной к цене выполнения повторной оптимизации. Являются возможными и рассматриваются в настоящем раскрытии и другие показатели цены, такие как минимизация цены непроизводительных издержек повторной оптимизации, например посредством сравнения цены повторной оптимизации с пороговым значением.
Фиг. 17 является блок-схемой 1700 способа (выполняемого процессорами 112а, 112b) реализации согласующего протокола согласно варианту осуществления.
В блоке 1705 запрашивающий процессор 112а (ЦП 1) отправляет запрос (такой как запросы 505, 605) на данные к удаленному процессору 112b (ЦП 2) через межсоединение 122. В блоке 1710 запрашивающий процессор 112а (ЦП 1) получает ответ (такой как ответы 1005, 1105) от удаленного процессора 112b, причем ответ включает в себя состояние транзакции (например, состояние прекращения транзакции 1010) удаленной транзакции (например, транзакция 320b) на удаленном процессоре 112b. В блоке 1715 запрашивающий процессор 112а добавляет состояние транзакции (информация из поля 1010) удаленной транзакции на удаленном процессоре в таблицу отслеживания взаимного вмешательства локальных транзакций (например, в таблицу 1350а).
В дополнение к одному или нескольким описанным выше признакам, или в качестве альтернативы, другие варианты осуществления могут включать в себя добавление состояния транзакции удаленной транзакции к транзакционному диагностическому блоку (TBD) (посредством запрашивающего процессора 112а). Удаленная транзакция выполняется на удаленном процессоре 112b и прекращает выполнение на основании отправления запроса на данные к удаленному процессору. Запрос производится посредством запрашивающей транзакции (например, транзакции 320а), выполняющейся на отправляющем запрос запрашивающем процессоре 112а.
В дополнение к одному или нескольким описанным выше признакам, или в качестве альтернативы, другие варианты осуществления могут включать в себя на основании запроса запрашивающей транзакцией, вызывающего прекращение удаленной транзакции (например, транзакции 320b) на удаленном процессоре 112b, добавление запрашивающим процессором 112а состояния транзакции удаленной транзакции (полученного из поля 1010) к таблице 1350а отслеживания взаимного вмешательства локальных транзакций и увеличение отсчета числа прекращений транзакции, произошедших для удаленной транзакции (каждой конкретной прекращаемой транзакции 320b).
В дополнение к одному или нескольким описанным выше признакам, или в качестве альтернативы, другие варианты осуществления могут включать в себя указание состоянием транзакции удаленной транзакции, полученным запрашивающим процессором 112а в ответе 1005, 1105 от удаленного процессора 112b, на то, что удаленная транзакция (транзакция 320b) была вынуждена прекратиться на основании получения запроса 505, 605 от запрашивающего процессора 112а.
В дополнение к одному или нескольким описанным выше признакам, или в качестве альтернативы, другие варианты осуществления могут включать в себя, что таблица 1350а отслеживания взаимного вмешательства локальных транзакций содержит нескольких транзакций, испытавших взаимное вмешательство и прекращенных посредством запрашивающей транзакции 320а, выполняющейся на запрашивающем процессоре 112а. таблица 1350а отслеживания взаимного вмешательства локальных транзакций содержит информацию, описывающую удаленные транзакции 320b на удаленных процессорах 112b (и других процессорах). Описывающая удаленные транзакции 320b на удаленных процессорах 112а информация включает в себя по меньшей мере одно из: тип взаимного вмешательства, вызванного выполняющейся на процессоре запрашивающей транзакцией, идентификация или адрес каждой из удаленных транзакций, которые были прекращены запрашивающей транзакцией, идентификация каждого из удаленных процессоров, на которых произошло взаимное вмешательство, адрес каждой из удаленных транзакций, которые были прекращены, и/или показатель проделанной работы, выполненной каждой из удаленных транзакций до того, как быть прекращенной.
Технические эффекты и преимущества включают в себя согласующий протокол, расширенный для включения в себя дополнительной информации относительно состояния транзакции. Когда процессор находится в процессе транзакционного выполнения, согласующий запрос может принудить выполнение транзакции приемного процессора прекратиться вследствие обнаружения конфликта. Согласующий протокольный запрос расширяется дополнительной информацией о том, что приемный процессор прекратил свое транзакционное выполнение согласно вариантам осуществления.
Используемая в настоящем документе терминология служит исключительно целям описания конкретных вариантов осуществления и не предназначается для ограничения изобретения. При использовании в настоящем документе, формы единственного числа предназначены для включения в себя также и форм множественного числа, если только контекст не указывает на иное недвусмысленным образом. В последующем изложении подразумевается, что термины «содержит» и/или «содержащий» при их использовании в данном техническом описании задают присутствие заявленных признаков, целочисленных переменных, этапов, операций, элементов и/или компонентов, но не исключают присутствия или добавления одного или нескольких других признаков, целочисленных переменных, этапов, операций, элементов, компонентов и/или образованных ими групп.
Соответствующие материалы, и эквиваленты всех средств или этапов, равно как функциональные элементы в пунктах формулы изобретения ниже предназначаются для включения в себя любой структуры, материала или действия для выполнения функции в сочетании с другими требуемыми элементами, как конкретным образом заявлено. Описание настоящего изобретения представлено в целях иллюстрации и описания, но не предназначается для полного охвата или ограничения изобретения в заявленном виде. Многие модификации и изменения являются очевидными для средних специалистов в области техники без отступления от существа и объема настоящего изобретения. Вариант осуществления был выбран и описан с целью наилучшего объяснения принципов изобретения и практического применения, а также для обеспечения другим средним специалистам в области техники возможности понимания изобретения для различных вариантов осуществления с различными модификациями, как они подходят для конкретно рассматриваемого использования.
Описания различных вариантов осуществления настоящего изобретения были предложены в целях иллюстрации, но не предназначаются для полного охвата или ограничения заявленных вариантов осуществления. Многие модификации и изменения являются очевидными для средних специалистов в области техники без отступления от существа и объема описанных вариантов осуществления. Используемая в настоящем документе терминология выбрана для наилучшего объяснения принципов вариантов осуществления, практического применения или технического улучшения по сравнению с имеющимися в коммерческом доступе технологиями, или для обеспечения другим средним специалистам в области техники возможности понимания описанных в настоящем документе вариантов осуществления.
При рассмотрении теперь фиг. 18, на ней в общих чертах показан компьютерный программный продукт 1800 согласно варианту осуществления, который включает в себя машиночитаемый информационный носитель (носитель информации) 1802 и программные команды 1804.
Настоящее изобретение может быть представлено системой, способом и/или компьютерным программным продуктом. Компьютерный программный продукт может включать в себя машиночитаемый информационный носитель (или носители), имеющий на нем машиночитаемые программные команды, принуждающие процессор выполнять аспекты настоящего изобретения. Машиночитаемый информационный носитель может быть представлен материальным устройством, которое является способным к удержанию и сохранению команд для использования устройством выполнения команд. Машиночитаемый информационный носитель может быть представлен, например, но не ограничиваясь, устройством электронного хранения, магнитным запоминающим устройством, оптическим запоминающим устройством, электромагнитным запоминающим устройством, полупроводниковым запоминающим устройством или любой подходящей комбинацией из вышеупомянутого. Неисчерпывающий список более конкретных примеров машиночитаемого информационного носителя включает в себя последующее: портативная компьютерная дискета, жесткий диск, оперативная память (RAM), постоянная память (ROM), стираемая программируемая постоянная память (EPROM или флэш-память), статическая оперативная память (SRAM), переносной компакт-диск для однократной записи данных (CD-ROM), цифровой универсальный диск (DVD), карта памяти, гибкий диск, механически закодированное устройство, такое как перфокарты или выступающие структуры в канавке с записанными на них командами, а также любая подходящая комбинация из вышеупомянутого. Машиночитаемый информационный носитель, как он рассматривается в настоящем документе, не подлежит истолкованию в качестве представленного преходящими сигналами как таковыми, такими как радиоволны или другие свободно распространяющиеся электромагнитные волны, электромагнитные волны, распространяющиеся через волновод или другие среды передачи (например, проходящие через волоконно-оптический кабель световые импульсы), или передаваемые через провода электрические сигналы.
Описанные в настоящем документе машиночитаемые программные команды могут быть загружены в соответствующие устройства вычисления/обработки с машиночитаемого информационного носителя или во внешний компьютер или во внешнее устройство хранения через сеть, например Интернет, локальную сеть, глобальную сеть и/или беспроводную сеть. Сеть может содержать медные кабели передачи, волокна оптической передачи, беспроводную передачу, маршрутизаторы, брандмауэры, переключатели, шлюзы и/или граничные серверы. Карта сетевого адаптера или сетевой интерфейс в каждом устройстве вычисления/обработки получает машиночитаемые программные команды из сети и направляет машиночитаемые программные команды для хранения в машиночитаемый информационный носитель в пределах соответствующего устройства вычисления/обработки.
Машиночитаемые программные команды для выполнения операций настоящего изобретения могут быть представлены командами ассемблера, командами архитектуры системы команд (ISA), машинными командами, машинно-зависимыми командами, микрокодом, командами встроенного программного обеспечения, присваивающими значение состоянию данными, или иным исходным кодом или объектным кодом, записанным на любой комбинации из одного или нескольких языков программирования, включая сюда объектно-ориентированные языки программирования, такие как Smalltalk, С++ и т.п., а также обычные языки процедурного программирования, такие как язык программирования «С» или подобные языки программирования. Машиночитаемые программные команды могут выполняться полностью на компьютере пользователя, частично на компьютере пользователя, как автономный пакет программного обеспечения, частично на компьютере пользователя и частично на удаленном компьютере или полностью на удаленном компьютере или сервере. В последнем сценарии удаленный компьютер может быть присоединен к компьютеру пользователя через любой тип сети, включая сюда локальную сеть (LAN) или глобальную сеть (WAN), или присоединение может быть сделано к внешнему компьютеру (например, через Интернет с использованием Интернет-провайдера). В некоторых вариантах осуществления электронной схемы, включающие в себя, например, программируемые логические схемы, программируемые на месте вентильные матрицы (FPGA) или программируемые логические матрицы (PLA) могут выполнять машиночитаемые программные команды посредством использования информации о состоянии машиночитаемых программных команд для настройки электронной схемы с целью выполнения аспектов настоящего изобретения.
Аспекты настоящего изобретения описаны в настоящем документе с отсылками на иллюстрации в виде блок-схем и/или блок-диаграмм для способов, устройств (систем) и компьютерных программных продуктов согласно вариантам осуществления изобретения. Подразумевается, что каждый блок иллюстраций в виде блок-схем и/или блок-диаграмм, а также комбинации блоков на иллюстрациях в виде блок-схем и/или блок-диаграмм, может быть реализован посредством машиночитаемых программных команд.
Такие машиночитаемые программные команды могут быть предоставлены к процессору универсального компьютера, специализированного компьютера или другого программируемого устройства обработки данных для получения такой целевой аппаратной платформы, что выполняемые посредством процессора компьютера или другого программируемого устройства обработки данных команды создают средства для реализации функций/действий, заданных в блоке или блоках блок-схемы и/или блок-диаграммы. Такие машиночитаемые программные команды также могут быть сохранены в машиночитаемом информационном носителе, который может управлять компьютером, программируемым устройством обработки данных и/или другим устройством таким образом, что они функционируют особым способом, таким, что машиночитаемый информационный носитель, сохраняющий на себе команды, представляет собой изделие, содержащее команды, которые реализуют аспекты функций/действий, заданных в блоке или блоках блок-схемы и/или блок-диаграммы.
Машиночитаемые программные команды могут также быть загружены в компьютер, другое программируемое устройство обработки данных или другое устройство для принуждения к выполнению на компьютере, другом программируемом устройстве или другом устройстве серии эксплуатационных этапов для получения такого компьютерно-реализованного процесса, что выполняемые на компьютере, другом программируемом устройстве или другом устройстве инструкции реализуют функция/действия, заданные в блоке или блоках блок-схемы и/или блок-диаграммы.
Блок-схемы и блок-диаграммы на иллюстрациях показывают архитектуру, функциональность и функционирование возможных реализаций систем, способов и компьютерных программных продуктов согласно различным вариантам осуществления настоящего изобретения. В этом отношении каждый блок в блок-схемах или блок-диаграммах может представлять модуль, сегмент или участок команд, который содержит одну или несколько исполнимых команд для реализации указанной логической функции (функций). В некоторых альтернативных реализациях, отмеченные в блоке функции могут осуществляться в порядке, отличном от отмеченного на чертежах. Например, два блока, показанные следующими друг за другом, фактически могут быть выполнены по существу одновременно, или блоки могут иногда выполняться в обратном порядке, в зависимости от предусмотренной к выполнению функциональности. Необходимо также отметить, что каждый блок на иллюстрациях в виде блок-схем и/или блок-диаграмм, а также в комбинациях блоков на иллюстрациях в виде блок-схем и/или блок-диаграмм, может быть реализован посредством основанных на аппаратных средствах систем особого назначения, которые выполняют указанные функции или действия или выполняют комбинации аппаратных и компьютерных команд особого назначения.