Transactional Synchronization in Haswell
От: netch80 Украина http://netch80.dreamwidth.org/
Дата: 14.02.12 07:19
Оценка: 1 (1)
Вышло описание транзакционной синхронизации в следующих интеловских процессорах: раз, два.

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

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, как наверняка уже обнюхавшего эту тематику.
The God is real, unless declared integer.
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.