Реализация приобретения для выпуска из Unsafe.putOrdered *()?

Question

Как вы думаете, лучший ли способ реализации части приобретения/приобретения пары в Java?

Я пытаюсь смоделировать некоторые действия в приложении my, используя классическую семантику release/получения (без StoreLoad и без последовательной согласованности по потокам).

Существует несколько способов достижения приблизительного эквивалента хранилища в JDK. java.util.concurrent.Atomic*.lazySet() и базовые sun.misc.Unsafe.putOrdered*() являются наиболее часто цитируемыми подходами для этого. Однако нет очевидного способа реализовать загрузку.

• В JDK API, которые позволяют lazySet() в основном используют volatile переменные внутри, так что их магазин-релизы спариваются с летучими нагрузками. Теоретически энергозависимые нагрузки должны быть более дорогими, чем загрузка, и не должны обеспечивать ничего большего, чем чистая загрузка в контексте предыдущего хранилища.

• sun.misc.Unsafe не обеспечивает getAcquire()* эквивалентов putOrdered*() методов, даже если такие методы приобретают запланированы на предстоящий VarHandles API.

• Похоже, что это будет работать, это простая загрузка, а затем sun.misc.Unsafe.loadFence(). Это несколько обескураживает, что я не видел этого нигде. Это может быть связано с тем, что это довольно уродливый взлом.

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

Answer 1

Неустойчивое считывание - это именно то, что вы ищете.

Фактически, соответствующие летучие операции уже имеют семантику освобождения/получения (в противном случае это случается раньше, чем для парного волатильного чтения), но парные изменчивые операции должны быть не только последовательно последовательными (~ бывает-до), но также они должны быть в total synchronization order, вот почему StoreLoad барьер вставлен после volatile write: чтобы гарантировать общий порядок волатильной записи в разные местоположения, так что все потоки будут видеть эти значения в том же порядке.

Летучих считывающим приобретают семантику: proof от точки доступа кодового, также есть прямая рекомендация Дуга Lea в JSR-133 cookbook (LoadLoad и LoadStore барьеров после каждого летучего чтения).

также имеет семантику приобретения (proof), но используется для того, чтобы не читать значение (вы можете сделать то же самое с простым изменчивым чтением), но для предотвращения повторного чтения простых записей с последующим изменчивым чтением. Это используется в StampedLock для оптимистического чтения (см. StampedLock#validate реализация метода и использование).

Обновление после обсуждения в комментариях.

Давайте проверим, являются ли Unsafe#loadStore() и волатильными считаются одинаковыми и имеют семантику приобретения.

Я ищу точку доступа C1 compiler source code, чтобы избежать прочтения всех оптимизаций в C2. Он преобразует байт-код (фактически, а не байт-код, но его представление интерпретатора) в LIR (промежуточное представление низкого уровня), а затем переводит граф в фактические коды операций, зависит от целевой микроархитектуры.

Unsafe#loadFence является intrinsic который имеет _loadFence псевдоним. В C1 LIR generator он генерирует следующее:

case vmIntrinsics::_loadFence : 
if (os::is_MP()) __ membar_acquire(); 

где __ это макросы для генерации LIR.

Теперь давайте посмотрим на volatile, прочитав implementation в том же генераторе LIR. Он пытается вставить нулевые проверки, проверяет IRIW, проверяет, находится ли мы на x32 и пытается прочитать 64-битное значение (чтобы сделать некоторые магии с SSE/FPU) и, наконец, приводит нас к тому же коду:

if (is_volatile && os::is_MP()) { 
    __ membar_acquire(); 
} 

Ассемблерный генератор затем вставляет инструкции (-ы) для определения конкретной платформы here.

не глядя на конкретных реализаций (нет ссылки здесь, но все это можно найти в SRC/CPU/{$ cpu_model}/VM/c1_LIRAssembler _ {$ cpu_model} .cpp)

• SPARC

  void LIR_Assembler::membar_acquire() { 
      // no-op on TSO 
  } 
  

• x86

  void LIR_Assembler::membar_acquire() { 
      // No x86 machines currently require load fences 
  } 
  

• Aarch64 (слабая модель памяти, барьеры должны быть предварительно послал)

  void LIR_Assembler::membar_acquire() { 
      __ membar(Assembler::LoadLoad|Assembler::LoadStore); 
  } 
  

  Согласно aarch architecture description такой membar будет скомпилирован как dmb ishld инструкции после загрузки.

• PowerPC (также слабая модель памяти)

  void LIR_Assembler::membar_acquire() { 
      __ acquire(); 
  } 
  

  , который затем преобразуется в конкретные инструкции PowerPC lwsync.Согласно commentslwsync семантически эквивалентно

  lwsync заказов Магазин | Store, Load | Store, Load | Load, но не хранить | Load

  Но до тех пор, как PowerPC hasn» t любые более слабые барьеры, это единственный выбор для реализации семантики приобретения PowerPC.

Выводы

Летучие читает и Unsafe#loadFence() равны с точки зрения упорядочения памяти (но, возможно, не с точки зрения возможных оптимизаций компилятора), на наиболее популярных x86 это не-оп, и PowerPC является только поддерживаемая архитектура не имеет точных ограничений.

Answer 2

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

Вы можете сделать это с помощью комбинации

int permits = theUnsafe.getInt(object, offset); 
if (!enough(permits)) 
    permits = theUnsafe.getVolatileInt(object, offset); 

Эта модель может быть использована в кольцевых буферов, чтобы минимизировать отток строк кэша.