Всегда ли для спин-блокировок требуется барьер памяти? Дорогое ли вращение на барьере памяти?

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

Обязательно ли локальное вращение при чтении из памяти подразумевает, что I ВСЕГДА вставлять барьер памяти перед отжимом прочитал?

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

Какова стоимость прокрутки через барьер памяти, если нечего сбрасывать в буфер хранилища кеша? т.е. все, что делает процесс (в C), составляет

while ( 1 ) {
    __sync_synchronize();
    v = value;
    if ( v != 0 ) {
        ... something ...
    }
}

Правильно ли я предполагаю, что он свободен и не обременяет шина памяти с любым трафиком?

Другой способ выразить это - спросить: действует ли барьер памяти ничего, кроме: очистить буфер хранилища, применить его недействительности и не позволяют компилятору переупорядочение чтения / записи по его местоположению?

Дизассемблирование, __sync_synchronize (), по-видимому, переводится в:

lock orl

Из руководства Intel (аналогично туманно для новичков):

Volume 3A: System Programming Guide, Part 1 --   8.1.2

Bus Locking

Intel 64 and IA-32 processors provide a LOCK# signal that
is asserted automatically during certain critical memory
operations to lock the system bus or equivalent link.
While this output signal is asserted, requests from other
processors or bus agents for control of the bus are
blocked.

[...]

For the P6 and more recent processor families, if the
memory area being accessed is cached internally in the
processor, the LOCK# signal is generally not asserted;
instead, locking is only applied to the processor’s caches
(see Section 8.1.4, “Effects of a LOCK Operation on
Internal Processor Caches”).

Мой перевод: «когда вы говорите LOCK, это будет быть дорогим, но мы делает это только там, где это необходимо. "

@BlankXavier:

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

Я думаю, что по умолчанию простая запись - это запись WB (обратная запись), что означает, что они не не удаляются немедленно, но операции чтения будут принимать их самое последнее значение (я думаю, они называют это «пересылкой хранилища»). Поэтому я использую инструкцию CAS для писателя. Я обнаружил в руководстве Intel все эти различные типы реализаций записи (UC, WC, WT, WB, WP), Intel vol 3A, главы 11-10, все еще учусь о них.

Моя неуверенность на стороне читателя: я понимаю из статьи МакКенни, что существует также очередь признания недействительности, очередь входящих аннулирований из шины в кэш. Я не уверен, как работает эта часть. В частности, вы, кажется, подразумеваете, что цикл через нормальное чтение (то есть без блокировки, без барьера и с использованием volatile только для обеспечения того, чтобы оптимизатор оставил чтение после компиляции), каждый раз будет проверять "очередь недействительности" (если такое существует). Если простого чтения недостаточно (т. Е. Можно прочитать старую строку кеша, которая все еще остается действительной в ожидании признания недействительности в очереди (для меня это тоже звучит немного бессвязно, но как тогда работают очереди недействительности?)), Тогда атомарное чтение будет будет необходимо, и мой вопрос: в таком случае, повлияет ли это на автобус? (Я думаю, что, вероятно, нет.)

Я все еще читаю руководство Intel, и, хотя я вижу отличное обсуждение переадресации хранилища, я не нашел хорошего обсуждения очередей недействительности. Я решил преобразовать свой код на C в ASM и поэкспериментировать, я думаю, что это лучший способ действительно почувствовать, как это работает.