В настоящее время активно развивается альтернативный подход к созданию масштабируемых и потокобезопасных параллельных программ для многопроцессорных систем с общей памятью - технология транзакционной памяти (transactional memory). Ожидается, что она войдет в стандарт языка С++17. В данной работе предложен метод оптимизации обнаружения конфликтов (конкурентного доступа потоков к общим областям памяти), возникающих при выполнении параллельных программ на базе транзакционной памяти. Реализован модуль компилятора GCC для профилирования параллельных программ и адаптивной настройки параметров реализации транзакционной памяти под программу. Эффективность метода исследована на тестовых программах из пакета STAMP. Ключевые слова: программная транзакционная память, параллельное программирование, профилирование, компиляторы.
Оптимизация обнаружения конфликтов в параллельных программах с транзакционной памятью \ast Федеральное государственное бюджетное образовательное учреждение высшего образования «Сибирский государственный университет телекоммуникаций и информатики»1, Федеральное государственное автономное образовательное учреждение высшего образования «Санкт-Петербургский государственный электротехнический университет «ЛЭТИ» им. В.И. Ульянова (Ленина)»2 function hashtable_add (h , key , value ) lock_acquire () i = hash ( key ) list_add_front (h[i], key , value ) lock_release () end function
Рис. 1. Добавление пары (key, value) в хеш-таблицу h
данных (lock-free data structures) [2] и транзакционная память (ТП, transactional memory) [
Менее трудоемким и прозрачным для программиста видится использование технологии транзакционной памяти, основная идея которой заключается в защите от конкурентного доступа области памяти программы, а не участка кода, как в случае использования блокировок на базе мьютексов. Известны как программные реализации транзакционной памяти (software transactional memory – STM): LazySTM, TinySTM, GCC TM, DTMC, RSTM, STMX, STM Monad, так и аппаратные реализации в процессорах (hardware transactional memory): Intel TSX, AMD ASF, Oracle Rock, IBM POWER8, IBM PowerPC A2.
В рамках программной транзакционной памяти программисту предоставляются языковые конструкции или API для формирования в программе транзакционных секций (transactional section) – участков кода, в которых осуществляется защита совместно используемых областей памяти. Выполнение потоками таких секций осуществляется без их блокирования. На среду выполнения (runtime) ложатся задачи по контролю за корректностью выполнения транзакций. Если во время выполнения транзакции другие потоки одновременно с ней не модифицировали защищенную область памяти, то транзакция считается корректной, и она фиксируется. Если же два или более потока при выполнении транзакций обращаются к одной и той же области памяти и как минимум один из них выполняет операцию записи, то возникает конфликт (аналог состояния гонки данных). Для его разрешения выполнение одной или нескольких транзакций может быть либо приостановлено (до завершения конфликтующей транзакции), либо прервано, а все модифицированные ими (их потоками) области памяти приведены в исходное состояние (на момент старта транзакции) – отмена транзакции и восстановление (cancel and rollback).
Для того чтобы обнаруживать конфликты, runtime-система должна отслеживать попытки одновременного доступа к одной и той же области памяти. Это реализуется путем поддержки информации о состоянии защищаемых регионов памяти. Возможны два уровня гранулярности контролируемых областей: уровень программных объектов (object-based STM) и уровень слов памяти (word-based STM).
Уровень программных объектов подразумевает поддержку runtime-системой метаданных о состоянии каждого объекта программы. Например, объектов в С++-программе.
Для реализации уровня слов памяти в простейшем случае требуется каждый байт линейного адресного пространства процесса сопровождать метаданными, что является практически невозможным. Вместо этого линейное адресное пространство процесса разбивается на фиксированные блоки, каждый из которых сопровождается метаданными о состоянии (подход, подобный прямому отображению физических адресов на кеш-память процессора) [5, 6]. Это приводит к тому, что множеству областей памяти соответствуют одни метаданные, что является источником возникновения ложных конфликтов. Ложный конфликт (false conflict)– это ситуация, при которой два или более потока во время выполнения транзакции обращаются к разным участкам линейного адресного пространства, но отображаемым на одни и те же метаданные. Поэтому runtime-система воспринимает такую ситуацию как конфликт (data race), хотя на самом деле таковой отсутствует.
Ложные конфликты существенно снижают эффективность параллельных STM-программ. Поэтому остро стоит задача разработки алгоритмов обнаружения и сокращения числа ложных конфликтов в реализациях STM.
В данной работе предлагается метод оптимизации ложных конфликтов по результатам предварительного профилирования С/С++ STM-программы. Для чего разработан программный инструментарий, который позволяет выполнять профилирование STM-программ и варьировать параметры реализации runtime-библиотеки STM в компиляторе GCC (libitm). 2. Метод оптимизации обнаружения конфликтов
Международным комитетом ISO по стандартизации языка C++, в рамках рабочей группы WG21, ведутся работы по внедрению транзакционной памяти в стандарт языка. Окончательное внедрение планируется в стандарт С++17. На сегодняшний день предложен черновой вариант спецификации поддержки транзакционной памяти в С++ [7]. Она реализована в компиляторе GCC, начиная с версии 4.8 и предоставляет ключевые слова __transaction_atomic, __transaction_relaxed для создания транзакционных секций, а также __transaction_cancel для принудительной отмены транзакции.
Для выполнения транзакционных секций runtime-системой создаются транзакции. Транзакция (transaction) – это конечная последовательность операций транзакционного чтения/записи памяти. Операция транзакционного чтения выполняет копирование содержимого указанного участка общей памяти в соответствующий участок локальной памяти потока. Транзакционная запись копирует содержимое указанного участка локальной памяти в соответствующий участок общей памяти, доступной всем потокам.
Инструкции транзакций выполняются потоками параллельно (конкурентно). После завершения выполнения транзакция может быть либо зафиксирована (commit), либо отменена (cancel). Фиксация транзакции подразумевает, что все сделанные в рамках нее изменения памяти становятся необратимыми. При отмене транзакции ее выполнение прерывается, а состояние всех модифицированных областей памяти восстанавливается в исходное с последующим перезапуском транзакции (откат транзакции, rollback).
Отмена транзакции происходит в случае обнаружения конфликта – ситуации, при которой два или более потока обращаются к одному и тому же участку памяти и как минимум один из них выполняет операцию записи.
Для разрешения конфликта разработаны различные походы, например, можно приостановить на некоторое время или отменить одну из конфликтующих транзакций.
На рис. 2 представлен пример создания транзакционной секции, в теле которой выполняется добавление элемента в хэш-таблицу множеством потоков. После выполнения тела транзакционной секции каждый поток приступит к выполнению кода, следующего за ней, в случае отсутствия конфликтов. В противном случае поток повторно будет выполнять транзакцию до тех пор, пока его транзакция не будет успешно зафиксирована.
Основными аспектами реализации транзакционной памяти в runtime-системах являются: b\ulet политика обновления объектов в памяти; b\ulet стратегия обнаружения конфликтов; b\ulet метод разрешения конфликтов.
Политика обновления объектов в памяти определяет, когда изменения объектов в рамках транзакции будут записаны в память. Распространение получили две основные политики – ленивая и ранняя. Ленивая политика обновления объектов в памяти (lazy version management) откладывает все операции с объектами до момента фиксации транзакции. Все операции записываются в специальном журнале (redo log), который при фиксации используется для отложенного выполнения операций. Очевидно, что это замедляет опера/* Совместно используемая хеш -таблица */ hashtable_t *h; /* Код потоков */ void * thread_start ( void * arg ) { st ru ct data *d = ( st ru ct data *) arg ; prepareData (d ); /* Транзакционная секция */ __transaction_atomic { /* Добавление элемента в хеш -таблицу */ st ru ct data *d = ( st ru ct data *) arg ; hashtable_insert (h , d ); } цию фиксации, но существенно упрощает процедуры ее отмены и восстановления. Примером реализаций ТП, использующих данную политику, являются RSTM-LLT [8] и RSTMRingSW [9, 11].
Ранняя политика обновления (eager version management) предполагает, что все изменения объектов сразу записываются в память. В журнале отката (undo log) фиксируются все выполненные операции с памятью. Он используется для восстановления оригинального состояния модифицируемых участков памяти в случае возникновения конфликта. Эта политика характеризуется быстрым выполнением операции фиксации транзакции, но медленным выполнением процедуры ее отмены. Примерами реализаций, использующих раннюю политику обновления данных, являются GCC (libitm), TinySTM [5], LSA-STM [6], Log-TM [10], RSTM [8] и др.
Момент времени, когда инициируется алгоритм обнаружения конфликта, определяется стратегией обнаружения конфликтов. При отложенной стратегии (lazy conflict detection) алгоритм обнаружения конфликтов запускается на этапе фиксации транзакции [11]. Недостатком этой стратегии является то, что временной интервал между возникновением конфликта и его обнаружением может быть достаточно большим. Эта стратегия используется в RSTM-LLT [8] и RSTM-RingSW [8, 9, 11].
Пессимистичная стратегия обнаружения конфликтов(eager conflict detection)
запускает алгоритм их обнаружения при каждой операции обращения к памяти. Такой подход
позволяет избежать недостатков отложенной стратегии, но может привести к значительным
накладным расходам, а также, в некоторых случаях, может привести к увеличению числа
откатов транзакций. Стратегия реализована в TinySTM [5], LSA-STM [6] и TL2 [
Для обнаружения конфликтных операций требуется отслеживать изменения состояния используемых областей памяти. Информация о состоянии может соответствовать областям памяти различной степени гранулярности. Выбор гранулярности обнаружения конфликтов – один из ключевых моментов при реализации программной транзакционной памяти.
На сегодняшний день используются два уровня гранулярности: уровень программных объектов (object-based STM) и уровень слов памяти (word-based STM). Уровень программных объектов подразумевает отображение объектов модели памяти языка (объекты C++, Java, Scala) на метаданные runtime-библиотеки. При использовании уровня слов памяти осуществляется отображение блоков линейного адресного пространства процесса на метаданные. Метаданные хранятся в таблице, каждая строка которой соответствует объекту программы или области линейного адресного пространства процесса. В строке содержатся номер транзакции, выполняющей операцию чтения/записи памяти; номер версии отображаемых данных; их состояние и др. Модификация метаданных выполняется runtime-системой с помощью атомарных операций процессора.
В данной работе рассматривается реализация программной транзакционной памяти в компиляторе GCC, использующая уровень слов памяти (в версиях GCC 4.8+ размер блока – 16 байт).
На рис. 3 представлен пример организации метаданных транзакционной памяти с использованием уровня слов памяти (GCC 4.8+). Линейное адресное пространство процесса фиксированными блоками циклически отображается на строки таблицы, подобно кешу прямого отображения. Выполнение операции записи приведет к изменению поля «состояние» соответствующей строки таблицы на «заблокировано». Доступ к области линейного адресного пространства, у которой соответствующая строка таблицы помечена как «заблокировано», приводит к конфликту. Рис. 3. Таблица с метаданными транзакционной памяти GCC 4.8+ (word-based STM): B = 16, S = 219
Основными параметрами транзакционной памяти с использованием уровня слов
памяти являются число S строк таблицы и количество B адресов линейного адресного
пространства, отображаемых на одну строку таблицы. От выбора этих параметров зависит число
ложных конфликтов – ситуаций аналогичных ситуации ложного разделения данных при
работе кеша процессора. В текущей реализации GCC (4.8-5.1) эти параметры
фиксированы [
При отображении блоков линейного адресного пространства процесса на метаданные runtime-библиотеки возникают коллизии. Это неизбежно, так как размер таблицы метаданных гораздо меньше размера линейного адресного пространства процесса. Коллизии приводят к возникновению ложных конфликтов. Ложный конфликт – ситуация, при которой два или более потока во время выполнения транзакции обращаются к разным участкам линейного адресного пространства, но сопровождаемым одними и теми же метаданными о состоянии, и как минимум один поток выполняет операцию записи. Таким образом, ложный конфликт – это конфликт, который происходит не на уровне данных программы, а на уровне метаданных runtime-библиотеки.
Возникновение ложных конфликтов приводит к откату транзакций так же, как и возникновение обычных конфликтов, несмотря на то что состояние гонки за данными не возникает, что влечет за собой увеличение времени выполнения STM-программ. Сократив число ложных конфликтов, можно существенно уменьшить время выполнения программы.
На рис. 4 показан пример возникновения ложного конфликта в результате коллизии
отображения линейного адресного пространства на строку таблицы. Поток 1 при
выполнении операции записи над областью памяти с адресом A1 захватывает соответствующую
строку таблицы. Выполнение операции чтения над областью памяти с адресом A2 потоком
2 приводит к возникновению конфликта, несмотря на то что операции чтения и записи
выполняются над различными адресами. Последнее обусловлено тем, что 1 и 2 отображены
на одну строку таблицы метаданных.
Рис. 4. Пример возникновения ложного конфликта при выполнении двух транзакций (GCC 4.8+)
В работе [
Рис. 5. Хеш-таблица для хранения метаданных Авторами предложен метод, позволяющий сократить число ложных конфликтов в STMпрограммах. Предполагается, что метаданные организованы в виде таблицы с прямой адресацией. Суть метода заключается в автоматической настройке параметров S и B таблицы под динамические характеристики конкретной STM-программы. Метод включает три этапа.
Этап 1. Внедрение функций библиотеки профилирования в транзакционные секции. На первом этапе выполняется компиляция C/C++ STM-программы с использованием разработанного модуля анализа транзакционных секций и внедрения вызова функций библиотеки профилирования (модуль расширения GCC). В ходе статического анализа транзакционных секций STM-программ выполняется внедрение кода для регистрации обращений к функциям Intel TM ABI (_ITM_beginTransaction, _ITM_comitTransaction, _ITM_LU4, _ITM_WU4 и др.). Детали реализации модуля описаны ниже.
Этап 2. Профилирование программы. На данном этапе выполняется запуск STMпрограммы в режиме профилирования. Профилировщик регистрирует все операции чтения/записи памяти в транзакциях. В результате формируется протокол (trace), содержащий информацию о ходе выполнения транзакционных секций: b\ulet адрес и размер области памяти, над которой выполняется операция; b\ulet временная метка (timestamp) начала выполнения операции.
Этап 3. Настройка параметров таблицы. По протоколу определяются средний размер W читаемой/записываемой области памяти во время выполнения транзакций. По значению W подбираются субоптимальные параметры B и S таблицы, с которыми STM-программа компилируется. Эксперименты с тестовыми STM-программами из пакета STAMP (6 типов STM-программ) позволили сформулировать эвристические правила для подбора параметров B и S по значению W . Значение параметра S целесообразно выбирать из множества {\ 218, 219, 220, 221\} . Значение параметра B выбирается следующим образом: b\ulet если W = 1 байт, то B = 24 байт; b\ulet если W = 4 байт, то B = 26 байт; b\ulet если W = 8 байт, то B = 27 байт; b\ulet если W >= 64 байт, то B = 28 байт. 3. Программный инструментарий для сокращения ложных конфликтов Авторами разработан программный инструментарий (STM false conflict optimizer) для оптимизации ложных конфликтов, возникающих при выполнении параллельных программ с транзакционной памятью. Инструментарий позволяет выполнять профилирование STMпрограмм. Информация, полученная в результате профилирования, предоставляет достаточно сведений о динамических характеристиках транзакционных секций для того, чтобы ответить на вопрос: «Фиксации каких транзакций или операции над какими данными приводят к отмене других транзакций?». Кроме этого, разработанное программное средство позволяет определить значения субоптимальных значений параметров реализации runtimeсистемы ТП, а именно число строк таблицы метаданных о состоянии областей памяти и количество адресов линейного адресного пространства, отображаемых на одну строку таблицы. 3.1. Функциональная структура пакета Программный инструментарий состоит из трех основных компонентов (рис. 6): b\ulet модуль внедрения функций библиотеки профилирования в код транзакционных секций (tm_prof _analyzer); b\ulet библиотека профилирования параллельной программы с транзакционной памятью (libitm_prof ); b\ulet модуль анализа протокола выполнения транзакционных секций, установки значений параметров реализации (tm_proto_analyzer). 3.2. Внедрение функций профилировщика
STM-компилятор осуществляет трансляцию транзакционных секций в
последовательность вызовов функций runtime-системы поддержки TM [
В общем случае последовательность выполнения транзакции следующая: Рис. 6. Функциональная структура разработанного пакета; 1 – компиляция STM-программы; 2 – запуск STM-программы под управление профилировщика; 3 – обращение к функциям профилировщика } ... Рис. 7. Трансляция транзакционной секции компилятором GCC; код слева – исходная транзакционная секция; код справа – промежуточное представление трансформированной транзакционной секции 1. Создание транзакции (вызов _ITM_beginTransaction) и анализ ее состояния. Если состояние транзакции содержит флаг принудительной отмены, то выполнение продолжается с метки <L3>, т.е. осуществляется выход из транзакции, иначе выполнение тела транзакции начинается с метки <L2>. 2. Выполнение транзакции. Если выполняется принудительная отмена транзакции, то в состоянии устанавливается флаг принудительной отмены (a_abortTransaction) и управление передается метке <L1>. 3. Попытка фиксации транзакции (вызов _ITM_commitTransaction). В случае возникновения конфликта транзакция отменяется, в состояние транзакции записывается причина отмены и выполнение транзакции повторяется начиная с метки <L1>. Разработанный модуль tm_prof _analyzer внедрения функций библиотеки профилирования выполнен в виде встраиваемого модуля компилятора GCC. Программист компилирует STM-программу с ключом - f plugin = tm_prof _analyzer.so. Модуль внедрения выполняет анализ промежуточного представления GIM P LE транзакционных секций и добавляет функции регистрации обращений к функциям Intel TM ABI: регистрация начала транзакции и ее фиксации, транзакционное чтения/запись областей памяти. На рис. 8 представлен пример внедрения вызовов функций библиотеки профилирования в транзакционную секцию. Функции с префиксом tm_prof _ выполняют регистрацию событий. } _ITM_commitTransaction (); tm_prof_commit (); Рис. 8. Встраивание в транзакционную секцию функций библиотеки профилирования; код слева – исходная транзакционная секция; код справа – промежуточное представление трансформированной транзакционной секции
Во время выполнения STM-программы под управлением профилировщика (libitm_prof ), функции регистрации обращений к интерфейсам Intel TM ABI заносят в протокол адреса и размер областей памяти, над которыми выполняются операции, а также время начала выполнения операций. После завершения выполнения STM-программы формируется протокол выполнения программы, на основе которого модуль анализа (tm_proto_analyzer) осуществляет выбор субоптимальных параметров таблицы метаданных транзакционной памяти. 4. Эксперименты
Экспериментальное исследование проводилось на вычислительной системе, оснащенной
двумя четырехъядерными процессорами Intel Xeon E5420. В данных процессорах
отсутствует поддержка аппаратной транзакционной памяти (Intel TSX). В качестве тестовых
программ использовались многопоточные STM-программы из пакета STAMP [
В рамках экспериментов измерялись значения двух показателей: b\ulet время t выполнения STM-программы; b\ulet количество C ложных конфликтов в программе.
На рис. 9 и 10 показана зависимость количества C ложных конфликтов и времени t выполнения теста от числа потоков при различных значениях параметров B и S. Результаты приведены для программы genome из пакета STAMP. В ней порядка 10 транзакционных секций, реализующих операции над хеш-таблицей и связными списками. Видно, что увеличение значений параметров S и B приводит к уменьшению числа возможных коллизий (ложных конфликтов), возникающих при отображении адресов линейного адресного пространства процесса на записи таблицы. При размере таблицы 221 записей, на каждую из Рис. 9. Зависимость числа C ложных конфликтов (слева) и времени t выполнения теста (справа) от числа N потоков: S = 219 Рис. 10. Зависимость числа C ложных конфликтов (слева) и времени t выполнения теста (справа) от числа N потоков: B = 26 которых отображается 26 адресов линейного адресного пространства, достигается минимум времени выполнения теста genome, а также минимум числа ложных конфликтов.
Время выполнения теста genome удалось сократить в среднем на 20% за счет минимизации числа ложных конфликтов. 5. Заключение
В рамках данной работы создан программный инструментарий сокращения числа ложных конфликтов в STM-программах. Предложен метод оптимизации параметров внутренних структур данных runtime-библиотеки транзакционной памяти компилятора GCC (libitm) под конкретное приложение. Используя предложенный метод, время выполнения теста genome удалось сократить на 20% за счет минимизации числа ложных конфликтов.
В дальнейшем планируется разработать алгоритм реализаций программной транзакционной памяти без централизованного хранения метаданных о состоянии областей памяти процесса. Литература 1. M. Herlihy, N. Shavit. The Art of Multiprocessor Programming. Morgan Kaufmann Publishers Inc., San Francisco, CA, USA, 2008. 2. Hendler D., Shavit N., Yerushalmi L. A scalable lock-free stack algorithm // Proceedings of the sixteenth annual ACM symposium on Parallelism in algorithms and architectures.
SPAA ’04. 2004. P. 206–215. 4. N. Shavit, D. Touitou. Software Transactional Memory. In PODC’95: Proceedings of the fourteenth annual ACM symposium on Principles of distributed computing, New York, NY, USA, Aug. 1995. ACM, 204–213. 7. Victor Luchango, Jens Maurer, Mark Moir. Transactional memory for C++ [PDF].
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3718.pdf 8. Rochester Software Transactional Memory Runtime. Project web site [HTML].
www.cs.rochester.edu/research/synchronization/rstm/. 9. Michael F. Spear, Luke Dalessandro, Virendra J. Marathe, and Michael L. Scott. A comprehensive strategy for contention management in software transactional memory. In PPoPP ’09: Proc. 14th ACM SIGPLAN Symposium on Principles and Practice of Parallel Programming, February 2009, P – 141-150. 10. Kevin E. Moore, Jayaram Bobba, Michelle J. Moravan, Mark D. Hill, and David A. Wood.
LogTM: Log-based transactional memory. In HPCA ’06: Proc. 12th International Symposium on High-Performance Computer Architecture, February 2006, P. – 254-265. 11. Michael F. Spear, Maged M. Michael, and Christoph von Praun. RingSTM: scalable transactions with a single atomic instruction. In SPAA ’08: Proc. 20th Annual Symposium on Parallelism in Algorithms and Architectures, June 2008, P. 275–284. 12. Dave Dice, Ori Shalev, and Nir Shavit. Transactional locking II. In DISC ’06: Proc. 20th International Symposium on Distributed Computing, September 2006. Springer Verlag Lecture Notes in Computer Science volume 4167, P. – 194-208. 13. Pascal Felber, Christof Fetzer, Torvald Riegel. Dynamic performance tuning of word-based software transactional memory. PPOPP 2008. P. – 237-246. 14. Craig Zilles and Ravi Rajwar. Implications of false conflict rate trends for robust software transactional memory. In IISWC ’07: Proc. 2007 IEEE. 15. Olszewski M., Cutler J., Stefan J. G. JudoSTM: A Dynamic Binary-Rewriting Approach to Software Transactional Memory. Proceedings of the 16th International Conference on Parallel Architecture and Compilation Techniques. PACT ’07. 2007. P. 365–375. 16. Intel Corporation. Intel Transactional Memory Compiler and Runtime Application Binary Interface. Revision: 1.0.1, November 2008. Optimization of conflict detection in parallel programs with transactional memory
I.I. Kulagin1, M.G. Kurnosov2 Transactional memory is a perspective abstraction for the creating a scalable parallel programs for multi-core systems. It will be included in C++17. In this work, are proposed optimization method of conflicts detection, that accur in parallel programs with the software transactional memory during execution. The autors have implemented a module for GCC compiler for profiling parallel programs with software transactional memory and a tool for adaptive tuning runtime-library. The eficiency of method is investigated on the STAMP benchmarks. 1. M. Herlihy, N. Shavit. The Art of Multiprocessor Programming. Morgan Kaufmann
Publishers Inc., San Francisco, CA, USA, 2008. 2. Hendler D., Shavit N., Yerushalmi L. A scalable lock-free stack algorithm // Proceedings of the sixteenth annual ACM symposium on Parallelism in algorithms and architectures.
SPAA ’04. 2004. P. 206–215. 4. N. Shavit, D. Touitou. Software Transactional Memory. In PODC’95: Proceedings of the fourteenth annual ACM symposium on Principles of distributed computing, New York, NY, USA, Aug. 1995. ACM, 204–213. 5. Pascal Felber, Christof Fetzer, Patrick Marlier, and Torvald Riegel, Time-based Software Transactional Memory, IEEE Transactions on Parallel and Distributed Systems, Volume 21, Issue 12, pp. 1793-1807, December 2010. 6. Torvald Riegel, Pascal Felber, and Christof Fetzer. A Lazy Snapshot Algorithm with Eager
Validation, 20th International Symposium on Distributed Computing (DISC), 2006. 7. Victor Luchango, Jens Maurer, Mark Moir. Transactional memory for C++ [PDF].
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3718.pdf 8. Rochester Software Transactional Memory Runtime. Project web site [HTML].
www.cs.rochester.edu/research/synchronization/rstm/. 9. Michael F. Spear, Luke Dalessandro, Virendra J. Marathe, and Michael L. Scott. A comprehensive strategy for contention management in software transactional memory. In PPoPP ’09: Proc. 14th ACM SIGPLAN Symposium on Principles and Practice of Parallel Programming, February 2009, P – 141-150. 10. Kevin E. Moore, Jayaram Bobba, Michelle J. Moravan, Mark D. Hill, and David A. Wood.
LogTM: Log-based transactional memory. In HPCA ’06: Proc. 12th International Symposium on High-Performance Computer Architecture, February 2006, P. – 254-265. 11. Michael F. Spear, Maged M. Michael, and Christoph von Praun. RingSTM: scalable transactions with a single atomic instruction. In SPAA ’08: Proc. 20th Annual Symposium on Parallelism in Algorithms and Architectures, June 2008, P. 275–284.