Неустойчивый дорогой?

На Intel неконтролируемое чтение изменчивой информации обходится довольно дешево. Если мы рассмотрим следующий простой случай:

public static long l;

public static void run() {        
    if (l == -1)
        System.exit(-1);

    if (l == -2)
        System.exit(-1);
}

Используя способность Java 7 печатать ассемблерный код, метод run выглядит примерно так:

# {method} 'run2' '()V' in 'Test2'
#           [sp+0x10]  (sp of caller)
0xb396ce80: mov    %eax,-0x3000(%esp)
0xb396ce87: push   %ebp
0xb396ce88: sub    $0x8,%esp          ;*synchronization entry
                                    ; - Test2::run2@-1 (line 33)
0xb396ce8e: mov    $0xffffffff,%ecx
0xb396ce93: mov    $0xffffffff,%ebx
0xb396ce98: mov    $0x6fa2b2f0,%esi   ;   {oop('Test2')}
0xb396ce9d: mov    0x150(%esi),%ebp
0xb396cea3: mov    0x154(%esi),%edi   ;*getstatic l
                                    ; - Test2::run@0 (line 33)
0xb396cea9: cmp    %ecx,%ebp
0xb396ceab: jne    0xb396ceaf
0xb396cead: cmp    %ebx,%edi
0xb396ceaf: je     0xb396cece         ;*getstatic l
                                    ; - Test2::run@14 (line 37)
0xb396ceb1: mov    $0xfffffffe,%ecx
0xb396ceb6: mov    $0xffffffff,%ebx
0xb396cebb: cmp    %ecx,%ebp
0xb396cebd: jne    0xb396cec1
0xb396cebf: cmp    %ebx,%edi
0xb396cec1: je     0xb396ceeb         ;*return
                                    ; - Test2::run@28 (line 40)
0xb396cec3: add    $0x8,%esp
0xb396cec6: pop    %ebp
0xb396cec7: test   %eax,0xb7732000    ;   {poll_return}
;... lines removed

Если вы посмотрите на 2 ссылки на getstatic, первая включает в себя загрузку из памяти, вторая пропускает загрузку, поскольку значение повторно используется из регистров, в которые оно уже загружено (long - 64 бит, а на моем 32-битном ноутбуке он использует 2 регистра).

Если мы сделаем переменную l изменчивой, то в результате сборка будет другой.

# {method} 'run2' '()V' in 'Test2'
#           [sp+0x10]  (sp of caller)
0xb3ab9340: mov    %eax,-0x3000(%esp)
0xb3ab9347: push   %ebp
0xb3ab9348: sub    $0x8,%esp          ;*synchronization entry
                                    ; - Test2::run2@-1 (line 32)
0xb3ab934e: mov    $0xffffffff,%ecx
0xb3ab9353: mov    $0xffffffff,%ebx
0xb3ab9358: mov    $0x150,%ebp
0xb3ab935d: movsd  0x6fb7b2f0(%ebp),%xmm0  ;   {oop('Test2')}
0xb3ab9365: movd   %xmm0,%eax
0xb3ab9369: psrlq  $0x20,%xmm0
0xb3ab936e: movd   %xmm0,%edx         ;*getstatic l
                                    ; - Test2::run@0 (line 32)
0xb3ab9372: cmp    %ecx,%eax
0xb3ab9374: jne    0xb3ab9378
0xb3ab9376: cmp    %ebx,%edx
0xb3ab9378: je     0xb3ab93ac
0xb3ab937a: mov    $0xfffffffe,%ecx
0xb3ab937f: mov    $0xffffffff,%ebx
0xb3ab9384: movsd  0x6fb7b2f0(%ebp),%xmm0  ;   {oop('Test2')}
0xb3ab938c: movd   %xmm0,%ebp
0xb3ab9390: psrlq  $0x20,%xmm0
0xb3ab9395: movd   %xmm0,%edi         ;*getstatic l
                                    ; - Test2::run@14 (line 36)
0xb3ab9399: cmp    %ecx,%ebp
0xb3ab939b: jne    0xb3ab939f
0xb3ab939d: cmp    %ebx,%edi
0xb3ab939f: je     0xb3ab93ba         ;*return
;... lines removed

В этом случае обе ссылки getstatic на переменную l включают загрузку из памяти, то есть значение не может храниться в регистре при многократном чтении с изменяемой памятью. Чтобы обеспечить атомарное чтение, значение считывается из основной памяти в регистр MMX movsd 0x6fb7b2f0(%ebp),%xmm0, делая операцию чтения одной инструкцией (из предыдущего примера мы видели, что для 64-битного значения обычно требуется два 32-битных чтения в 32-битной системе).

Таким образом, общая стоимость энергозависимого чтения будет примерно эквивалентна загрузке памяти и может быть такой же дешевой, как доступ к кэш-памяти L1. Однако, если другое ядро ​​выполняет запись в изменчивую переменную, строка кэша будет недействительной, что потребует доступа к основной памяти или, возможно, к кэш-памяти L3. Фактическая стоимость будет сильно зависеть от архитектуры процессора. Даже у Intel и AMD протоколы согласованности кеша различаются.

Вообще говоря, на большинстве современных процессоров нестабильная нагрузка сопоставима с нормальной нагрузкой. Энергозависимый накопитель составляет примерно 1/3 времени montior-enter / monitor-exit. Это наблюдается в системах с когерентным кешем.

Чтобы ответить на вопрос OP, изменчивые записи дороги, в то время как чтения обычно нет.

Означает ли это, что операции чтения volatile могут выполняться без явного аннулирования кеша на x86 и происходят так же быстро, как и обычное чтение переменной (без учета ограничений переупорядочения volatile)?

Да, иногда при проверке поля ЦП может даже не воздействовать на основную память, вместо этого шпионит за другими кешами потоков и получает оттуда значение (очень общее объяснение).

Тем не менее, я повторяю предложение Нила о том, что если у вас есть поле, доступное для нескольких потоков, вы должны обернуть его как AtomicReference. Будучи AtomicReference, он выполняет примерно такую ​​же пропускную способность для чтения / записи, но также более очевидно, что к полю будут обращаться и изменять несколько потоков.

Изменить, чтобы ответить на редактирование OP:

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

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

Говоря словами модели памяти Java (как определено для Java 5+ в JSR 133), любая операция - чтение или запись - с переменной volatile создает отношение происходит до по отношению к любому другая операция с той же переменной. Это означает, что компилятор и JIT вынуждены избегать определенных оптимизаций, таких как переупорядочивание инструкций внутри потока или выполнение операций только в локальном кэше.

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

Тем не менее, вам не следует создавать переменную volatile, если вы не знаете, что к ней будут обращаться из нескольких потоков вне блоков synchronized. Даже тогда вы должны подумать, является ли volatile лучшим выбором по сравнению с synchronized, AtomicReference и его друзьями, явными Lock классами и т. Д.

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

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