Кто-нибудь пробовал транзакционную память для C ++?

StackOverflow https://stackoverflow.com/questions/82495

Вопрос

Я проверял сайт Intel "whatif" и их компилятор транзакционной памяти (каждый поток должен выполнять атомарные коммиты или откат системной памяти, как это сделала бы база данных).

Это кажется многообещающим способом замены блокировок и мьютексов, но я не могу найти много отзывов.У кого-нибудь здесь есть какие-нибудь предложения?

Это было полезно?

Решение

Я не использовал компилятор Intel, однако у Херба Саттера было несколько интересных комментариев по этому поводу...

От Саттер Говорит:Будущее параллелизма

Видите ли вы большой интерес к транзакционной памяти и ее использованию, или эта концепция слишком сложна для понимания большинством разработчиков?

Пока невозможно ответить, кто им пользуется, потому что он еще не вышел на рынок.У Intel есть прототип программного компилятора транзакционной памяти.Но если вопрос в том, "Не слишком ли сложно это использовать разработчикам?" ответ таков: я, конечно, надеюсь, что нет.Все дело в том, что это намного проще, чем замки.Это единственная важная вещь на горизонте исследований, которая дает надежду на значительное сокращение использования нами замков.Это никогда не заменит замки полностью, но это наша единственная большая надежда на их частичную замену.

Есть некоторые ограничения.В частности, некоторые операции ввода-вывода по своей сути не являются транзакционными — вы не можете взять атомарный блок, который запрашивает у пользователя его имя, и прочитать имя из консоли, и просто автоматически прервать и повторить блок, если он конфликтует с другой транзакцией;пользователь может заметить разницу, если вы дважды подскажете ему об этом.Однако транзакционная память отлично подходит для материалов, которые касаются только памяти.

У каждого крупного поставщика оборудования и программного обеспечения, которого я знаю, есть несколько инструментов для обработки транзакционной памяти в R & D.Проводятся конференции и научные доклады, посвященные теоретическим ответам на основные вопросы.Мы еще не достигли стадии разработки модели T, когда сможем ее выпустить.Вероятно, вы увидите ранние, ограниченные прототипы, в которых вы не можете использовать неограниченную транзакционную память — где вы можете читать и записывать только, скажем, 100 ячеек памяти.Тем не менее, это все еще очень полезно для включения большего количества алгоритмов без блокировок.

Другие советы

ДокторВ прошлом году у Добба была статья об этой концепции:Транзакционное программирование Калума Гранта -- http://www.ddj.com/cpp/202802978

Она включает в себя несколько примеров, сравнений и выводов с использованием его библиотеки примеров.

Я создал комбинаторную библиотеку STM поверх некоторых идей функционального программирования.Он не требует никакой поддержки компилятора (за исключением того, что использует C ++ 17), не привносит нового синтаксиса.В общем, он использует интерфейс Библиотека STM от Хаскелла.

Итак, моя библиотека обладает несколькими приятными свойствами:

  • Монадически комбинаторный.Каждая транзакция - это вычисление внутри пользовательской монады с именем STML.Вы можете объединять монадические транзакции в более крупные монадические транзакции.
  • Транзакции отделены от модели данных.Вы создаете свою параллельную модель данных с использованием транзакционных переменных (TVars) и запускать транзакции по нему.
  • Есть retry комбинатор.Это позволяет вам повторно запустить транзакцию.Очень полезно для построения коротких и понятных транзакций.
  • Существуют различные монадические комбинаторы для краткого выражения вычислений.
  • Есть Context.Каждое вычисление должно выполняться в некотором контексте, а не в глобальной среде выполнения.Таким образом, у вас может быть много разных контекстов, если вам нужно несколько независимых кластеров STM.
  • Концептуально реализация довольно проста.По крайней мере, эталонная реализация в Haskell это так, но мне пришлось заново изобрести несколько подходов для реализации на C ++ из-за отсутствия хорошей поддержки функционального программирования.

Библиотека демонстрирует очень хорошую стабильность и робастность, даже если мы считаем ее экспериментальной.Более того, мой подход открывает множество возможностей для улучшения библиотеки по производительности, возможностям, полноте охвата и т.д.

Чтобы продемонстрировать его работу, я решил следующую задачу Dining Philosophers задание.Вы можете найти код по ссылкам ниже.Пример транзакции:

STML<bool> takeFork(const TVar<Fork>& tFork)
{
    STML<bool> alreadyTaken = withTVar(tFork, isForkTaken);
    STML<Unit> takenByUs    = modifyTVar(tFork, setForkTaken);
    STML<bool> success      = sequence(takenByUs, pure(true));
    STML<bool> fail         = pure(false);
    STML<bool> result       = ifThenElse(alreadyTaken, fail, success);
    return result;
};

Обновить Я написал учебник, вы можете найти его здесь.

Sun Microsystems объявили, что в следующем году они выпускают новый процессор под кодовым названием Rock, который имеет аппаратную поддержку транзакционной памяти.Это будет иметь некоторые ограничения, но это хороший первый шаг, который должен облегчить программистам замену блокировок / мьютексов транзакциями и ожидайте от этого хорошей производительности.

Интересный доклад на эту тему, сделанный Марком Мойром, одним из исследователей Sun, работающих над транзакционной памятью и Rock, смотрите здесь Ссылка.

Для получения дополнительной информации и объявлений Sun о Rock и транзакционной памяти в целом, это Ссылка.

Обязательный статья в Википедии :)

Наконец-то, эта ссылка, в Университете Висконсин-Мэдисон, содержит библиографию большинства исследований, которые проводились и проводятся в настоящее время в области транзакционной памяти, будь то аппаратная или программная.

В некоторых случаях я считаю это полезным и даже необходимым.

Однако, даже если у процессора есть специальные инструкции, которые упрощают этот процесс, все равно возникают большие накладные расходы по сравнению с мьютексом или семафором.В зависимости от того, как это реализовано, это также может повлиять на производительность в реальном времени (придется либо останавливать прерывания, либо запрещать их запись в ваши общие области).

Я ожидаю, что если бы это было реализовано, то это было бы необходимо только для части данного пространства памяти, и поэтому влияние могло бы быть ограниченным.

-Адам

Лицензировано под: CC-BY-SA с атрибуция
Не связан с StackOverflow
scroll top