Стандартный статус транзакционной памяти C ++

Каков текущий статус предложения транзакционной памяти для C ++ 17. Будет ли он включен в стандарт с целью включения в какую-либо будущую версию стандарта C ++ или это всего лишь экспериментальная функция для проверки концепции, статус которой пока не определен?

Я спрашиваю, потому что некоторые документы комитета по стандартизации, кажется, содержат противоречивую информацию. С одной стороны, у нас есть P0265R0 (http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0265r0.pdf), говоря, что транзакционная память не будет стандартизирована, с другой стороны - есть статья N4492 от Страуструп (http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4492.pdf) с транзакционной памятью, указанной в списке функций C ++ 17.


c++ c++17 transactional-memory
person lukeg    schedule 19.08.2016    source источник

Ответы (1)


arrow_upward
6
arrow_downward

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

  • Не хватает опыта внедрения. Только g ++ реализует это, начиная с GCC6. Частично цель TS состоит в том, чтобы собрать реализацию и пользовательский опыт, поэтому такая большая функция все еще слишком «незрела» в этом отношении.

  • Не каждая цель поддерживает транзакционную память, и требует высокой стоимости внедрения, хотя не всем она нужна. По этим причинам комитет явно не уверен, должна ли TS вообще быть частью основного стандарта C ++. С таким же успехом он мог бы жить вечно, как TS.

  • Более того, не все считают, что каждая функция транзакционной памяти TS заслуживает включения в основной стандарт C ++. Некоторые считают, что synchronized является главной особенностью, в то время как другие считают, что атомные блоки действительно меняют правила игры. TS действительно добавляет еще одну когнитивную нагрузку, с которой придется иметь дело разработчикам библиотеки (а также несколько новых ключевых слов, что обычно не очень хорошо).

person Morwenn    schedule 19.08.2016
comment
Хороший ответ. Это позор, поскольку это единственная компонуемая техника в AFAICT. По сути, параллельное программирование в значительной степени похоже на то, что было 15 лет назад, когда все требует кодирования с нуля (опять же, поскольку ничто не может быть составлено, поэтому нет многоразовых строительных блоков). - person Ami Tavory; 19.08.2016
comment
@AmiTavory, что может быть чем-то, что транзакции более компонуемо, и почему? - person Janus Troelsen; 13.06.2017
comment
@JanusTroelsen Допустим, вы нашли какой-то проект, показывающий какой-то супер крутой алгоритм параллелизма для хеш-таблицы, использующий примитивы мьютекса или блокировки. Затем вы найдете то же самое для связанного списка. Затем вы хотите создать кеш LRU, используя хеш-таблицу и связанный список. AFAIU, комбинация этих решений, не является решением комбинации проблем (недостаточно одновременного использования хэш-таблицы и списка; состояние LRU может быть несовместимым). Однако, используя хеш-таблицу TSM и связанный список, вы можете тривиально построить TSM LRU. - person Ami Tavory; 13.06.2017