Вышло описание транзакционной синхронизации в следующих интеловских процессорах: раз, два.

Судя по этой цитате:

The two operations that map to the same hash table entry will need to be staggered. This will occur even if we are unlucky enough to have them happen at the same time. In such a case, the Intel TSX will detect that the lock was indeed needed and some locking overhead will be incurred.

мы имеем (в случае XBEGIN) по сути старый добрый LL/SC, но не для одной инструкции, а для всех между началом и коммитом. Это правильное понимание?

Правильно ли, что XACQUIRE и XRELEASE чётко соответствуют LL и SC в терминах конкурентов? (описание на это намекает)

Правильно ли я понял, что выбор префиксов (f2 и f3) позволяет тому же коду исполняться и на более старых процессорах без детекта собственно поддержки HLE, то есть гарантируется, что предыдущие процессоры их тупо игнорируют? (Есть намёк на это в документе.) Если так, то зачем это вообще сделано? Ведь если программа надеется на корректную проверку чужого вмешательства при SC, то будет нарушение синхронизации, а если не надеется, то внешний большой (coarse) лок сделает все внутренние прыжки вокруг LL/SC бессмысленными.

Насколько объёмной обещается поддержка RTM — в смысле объёма памяти в кэше, для которого ведётся учёт внешнего вмешательства? Ограничивается ли это только L1, L2? Слабо понятно, что делать, если код диагностики говорит про переполнение буферов без другой причины. В этом случае надо переводить реализацию на coarse блокировку, а смена метода блокировки на ходу — операция сложная и неприятная.

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

Здравствуйте, netch80, Вы писали:

N>Вышло описание транзакционной синхронизации в следующих интеловских процессорах: раз, два.

N>Судя по этой цитате:

The two operations that map to the same hash table entry will need to be staggered. This will occur even if we are unlucky enough to have them happen at the same time. In such a case, the Intel TSX will detect that the lock was indeed needed and some locking overhead will be incurred.

мы имеем (в случае XBEGIN) по сути старый добрый LL/SC, но не для одной инструкции, а для всех между началом и коммитом. Это правильное понимание?

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


N>Правильно ли, что XACQUIRE и XRELEASE чётко соответствуют LL и SC в терминах конкурентов? (описание на это намекает)

Я думаю, что нет. И XACQUIRE и XRELEASE — это сохранения, при этом они сами на самом деле не происходят. Все-таки это lock-elision это отдельная вещь.


N>Правильно ли я понял, что выбор префиксов (f2 и f3) позволяет тому же коду исполняться и на более старых процессорах без детекта собственно поддержки HLE, то есть гарантируется, что предыдущие процессоры их тупо игнорируют? (Есть намёк на это в документе.)

Да.

N>Если так, то зачем это вообще сделано? Ведь если программа надеется на корректную проверку чужого вмешательства при SC, то будет нарушение синхронизации, а если не надеется, то внешний большой (coarse) лок сделает все внутренние прыжки вокруг LL/SC бессмысленными.

Перфиксы XACQUIRE и XRELEASE ставятся перед инструкциями захвата и освобождения мьютекса. Поэтому на новых процессорах синхронизация (взаимное исключение) будет обеспечиваться транзакционной памятью, а в старых это по прежнему будет обычный мьютекс, который и будет обеспечивать взаимное исключение.


N>Насколько объёмной обещается поддержка RTM — в смысле объёма памяти в кэше, для которого ведётся учёт внешнего вмешательства? Ограничивается ли это только L1, L2? Слабо понятно, что делать, если код диагностики говорит про переполнение буферов без другой причины. В этом случае надо переводить реализацию на coarse блокировку, а смена метода блокировки на ходу — операция сложная и неприятная.

Это пока не раскрывается. Даже под NDA.
Я думаю, что это будет точно ограничено объемом L1 кэша, плюс возможно дополнительное ограничение типа 64 кэш-линий.
Для каких-то ограниченных алгоритмов синхронизации (типа поискать и добавить в хэш таблицу) этого должно хватать. А произвольный код неограниченно объёма не подразумевается, что будет выполняться внутри транзакции.
Если используется ACQUIRE/XRELEASE, то ручного переключения делать не надо, оно будет происходить автоматически. Если используются более общие XBEGIN/XEND, то нужно вручную определять их поддержку, и реализовывать резервный механизм синхронизации (мьютекс). Смена механизма сихронизации не должна быть очень сложно — если транзакция проваливается, то управление переходит на заданный адрес, там мы смотрим, что флажок "транзакция может удаться в следующий раз" и счетчик неудач, на основании этого решаем пробовать ещё раз или лочить мьютекс.