Записывает ли cmpxchg строку кэша назначения в случае сбоя? Если нет, то лучше xchg для спинлока?

На большинстве или всех современных процессорах Intel x86 lock cmpxchg в ячейку с типом памяти WB, полностью содержащуюся в одной строке кэша L1D, выполняется следующим образом:

• L1D выдает запрос чтения с блокировкой, который переводит целевую строку в состояние согласованности кэш-памяти с блокировкой и исключительным доступом и предоставляет запрошенные байты в качестве входных данных для одного из портов выполнения для выполнения сравнения. (Блокировка кэша поддерживается, начиная с P6.) Линия в заблокированном состоянии не может быть аннулирована или исключена по любой причине.
• Проведите сравнение на равенство.
• Каким бы ни был результат, отправьте запрос разблокировки-записи к L1D, который изменяет состояние строки кэша на Modified и разблокирует строку, тем самым позволяя другим запросам доступа или согласованности заменить или сделать строку недействительной.

Первый и последний этапы можно наблюдать эмпирически, используя либо определенные события производительности, либо измерения на основе задержки. Один из способов - выделить большой массив атомарных переменных и затем выполнить lock cmpxchg в цикле над этим массивом. Тип запроса чтения с блокировкой - это один из типов запросов RFO. Таким образом, событие L2_TRANS.RFO (или что-то подобное), которое надежно для большинства микроархитектур, можно использовать для измерения количества чтений блокировки в L2. (L2_TRANS.RFO подсчитывает запросы RFO, поэтому лучше отключить аппаратные средства предварительной выборки, чтобы избежать нежелательных попаданий в L2. Это также относится к L2_RQSTS.RFO_*.)

Также есть события для измерения количества обратных записей, такие как L2_TRANS.L1D_WB, L2_TRANS.L2_WB и другие. К сожалению, многие из этих событий и во многих микроархитектурах либо занижены, либо превышены, либо подсчитываются точно, но не обязательно все / только обратные записи строк грязного кэша. Так что с ними труднее рассуждать, и в целом они ненадежны.

Лучшим способом было бы выполнить lock cmpxchg в одном разделе массива на определенном физическом ядре, затем перенести поток на другое физическое ядро ​​(в том же домене совместного использования L3) и выполнить цикл, в котором считываются элементы этого раздела ( нормально читает). Если инструкция lock cmpxchg переводит целевую строку в состояние M, запрос на чтение из другого физического ядра в том же домене совместного использования L3 должен попасть в L3, а также изменен в частных кэшах ядра, на котором было выполнено lock cmpxchg. Эти события можно подсчитать с помощью OFFCORE_RESPONSE.DEMAND_DATA_RD.L3_HIT.HITM_OTHER_CORE (или аналогичного), что надежно для большинства / всех микроархитектур.

Заблокированная инструкция - дорогостоящая операция по трем причинам: (1) требует перевода строки в исключительное состояние, (2) делает строку грязной (возможно, излишне) и слишком большое количество обратных записей может существенно повлиять на время выполнения, тем более когда они в конечном итоге крадут полосу пропускания основной памяти из-за длинных отрезков запросов на чтение, и тем более, когда записи производятся в постоянную память, и (3) они архитектурно сериализуются, что делает инструкцию по критическому пути.

У Intel есть патент, который предлагает оптимизацию для последнего, причем ядро ​​оптимистично предполагает, что есть не вызывает конкуренции за блокировку и вызывает спекулятивную нормальную нагрузку на целевую линию. Если линия отсутствует в каком-либо другом физическом ядре, линия будет в исключительном состоянии в запрашивающем ядре. Затем, когда заблокированная инструкция выполняется и выдает запрос чтения блокировки, линия, будем надеяться, все еще будет в исключительном состоянии, и в этом случае общая задержка заблокированной инструкции будет уменьшена. Я не знаю, реализует ли какой-либо процессор эту оптимизацию. Если бы это было реализовано, количество L2_TRANS.RFO событий было бы намного меньше, чем количество заблокированных строк.

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

До сих пор не наблюдалось устойчивого эффекта разницы между lock bts xchg или lock cmpxchg.

Однако кое-что повлияло и на другие вещи:

• Внутренний load цикл определенно полезен, как с pause, так и без него.
• Один pause в цикле полезен как с циклом загрузки, так и без него.
• Цикл нагрузки помогает больше, чем просто пауза
• Наилучшие результаты достигаются при применении улучшенной версии из Справочного руководства по оптимизации архитектур Intel® 64 и IA-32 (см. Ниже)
• Запуск с нагрузкой вместо RMW / CAS имеет противоречивый эффект: он полезен для тестов без pause, но снижает производительность тестов с pause

Intel® Справочное руководство по оптимизации архитектур 64 и IA-32 рекомендует использовать pause.

Пример 2-4. Пример конкурирующих блокировок с увеличивающимся откатом показывает базовую версию:

/*******************/
/*Baseline Version */
/*******************/
// atomic {if (lock == free) then change lock state to busy}
while (cmpxchg(lock, free, busy) == fail)
{
 while (lock == busy)
 {
 __asm__ ("pause");
 }
}

и улучшенная версия:

/*******************/
/*Improved Version */
/*******************/
int mask = 1;
int const max = 64; //MAX_BACKOFF
while (cmpxchg(lock, free, busy) == fail)
{
 while (lock == busy)
 {
   for (int i=mask; i; --i){
     __asm__ ("pause");
   }
   mask = mask < max ? mask<<1 : max;
 }
}

Windows SRWLOCK также может быть хорошим примером для подражания. Он использует цикл загрузки и pause. он начинается с взаимосвязанной операции lock bts для монопольного получения, lock cmpxchg для совместного использования. Даже TryAcquireSRWLockExclusive делает только lock bts:

RtlTryAcquireSRWLockExclusive:
00007FFA86D71370  lock bts    qword ptr [rcx],0  
00007FFA86D71376  setae       al  
00007FFA86D71379  ret  

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