Pull to refresh
0

Анонсирована аппаратная поддержка транзакционной памяти в Haswell

Reading time 4 min
Views 14K
Haswell будет очень инновационным Tock'ом. Еще в прошлом году стало доступно описание новых операций с целыми в AVX. А на этой неделе было опубликовано очередное расширение архитектуры X86. В Haswell появится аппаратная поддержка транзакционной памяти! На англоязычных сайтах обсуждение кипит. ISN Arstechnica LWN Engadget

Я думаю, что это самое нетривиальное расширение архитектуры X86 за много-много лет. Фича называется Transactional Synchronization Extensions (далее TSX), и состоит из двух частей — Hardware Lock Elision (HLE) и Restricted Transactional Memory (RTM). Обратите внимание на слово «Restricted». Все верно, есть некоторые ограничения по объему, гранулярности и уровню вложенности транзакций.

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

Software Transactional Memory (STM) — достаточно известная концепция. В двух словах ее суть в том, что определяются транзакции, внутри которых все изменения любых участков памяти атомарно коммитятся при условии отсутствия конфликтов с другими потоками, или полностью отменяются при конфликте. У STM есть два ключевых преимущества перед параллелизмом с блокировками — потенциально лучшая scalability и удобство программирования (использовать транзакции намного проще, чем блокировки, и в отличие от блокировок, транзакции легко могут быть композитными).

Есть масса программных реализаций, например Intel STM compiler или TBoost.STM. Есть предложение о добавлении поддержки транзакционной памяти в С++. В моей любимой Clojure STM вообще единственный идиоматичный механизм многопоточной работы с разделяемой общей памятью.

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

Производители процессоров давно облизывались на поддержку Transactional Memory в железе. Это потенциально решило бы проблемы с производительностью. Например, был такой процессор UltraSPARC Rock с аппаратной поддержкой транзакционной памяти, но он, к сожалению, не взлетел. У Azul и IBM также есть работающее железо, поддерживающее транзакционную память.

Как все устроено в Haswell? Обычно начинают объяснение с HLE, потом идет RTM, а потом как оно устроено внутри. Я начну с внутренностей, потом перейду к RTM, и оставлю HLE напоследок, так будет интереснее.

В реализации кэша в Haswell появится некая магия, которая для каждой кэш линии будет определять ее принадлежность к read-set и write-set активных транзакций. Также появляются несколько новых u-ops, нужных чтобы начать и завершить транзакцию, узнать причину отката и для диагностики.

RTM — это просто использование этих новых инструкций программистом. Инструкция XBEGIN начинает транзакцию и устанавливает обработчик для прерванной транзакции, XEND — завершает, и XABORT прерывает. Естественно, если программа с RTM исполняется на X86 процессоре, не поддерживающем TSX, произойдет #UD.

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

Как же это было сделано? В некотором смысле HLE можно считать вариантом rw-lock для переменной, используемой для блокировки + транзакция :). Вводятся префиксы XAQUIRE и XRELEASE. Это не инструкции, это префиксы (типа LOCK, REP)! Они игнорируются процессором, который не поддерживает TSX. Эти префиксы рекомендуется использовать перед взятием блокировки и ее освобождением соответственно. При взятии блокировки, запись в переменную не происходит, вместо этого она помещается в read-set процесса, и начинается транзакция. Благодаря этой магии (или хаку, если будет так угодно) остальные процессы тоже могут исполнять залоченный код, пока не будет конфликта по write-set. Потом при XRELEASE и записи в блокировку(которая также игнорируется) транзакция коммитится, если исполнилась без конфликтов. Если конфликты были, то происходит возвращение к обычной семантике.

Перечислю ограничения TSX.
1. Так как гранулярность — 64 байта, неаккуратное размещение данных в памяти наряду с false sharing будет теперь вызвать false transaction abort… Так как read-set'ы и write-set'ы определены в кэше, это ограничивает объем памяти, с которой транзакция может успешно сработать.
2. Существует куча условий, когда транзакции обрываются. (При приходе прерывания, использовании инструкций типа PAUSE, X87, переключении контекста, отладке и т.д.)
3. Вложенность. Есть ограничение уровня вложенности. (Сорри не могу сказать, какое) Прерывание транзакции по любой причине на любом уровне вложенности сбрасывает все вложенные транзакции!
При прерывании транзакции можно посмотреть причину. Но все равно очень весело будет все это дебажить и профилировать! Конечно, для анализа производительности появятся новые CPU каунтеры, считающие связанные с TSX события.

Поддержка в софте уже начала появляться, например, в Binutils уже закоммитили. На очереди HLE в pthreads :), а потом, я надеюсь, использование RTM в реализациях STM.
Как я писал выше, подробности доступны в документе на сайте Intel.
Tags:
Hubs:
+24
Comments 14
Comments Comments 14

Articles

Information

Website
www.intel.ru
Registered
Founded
Employees
5,001–10,000 employees
Location
США
Representative
Анастасия Казантаева