lazySet може бути використаний для зв'язку між потоками Rmw, тому що xchg є атомним, як для видимості, коли процес потоку програми редагує місце розташування кеш-лінії, процесор потоку читача побачить це при наступному прочитанні, оскільки протокол узгодженості кешу Intel cpu гарантує LazySet працює, але рядок кешу буде оновлено при наступному прочитанні, знову ж таки, процесор повинен бути досить сучасним.
http://sc.tamu.edu/systems/eos/nehalem.pdf
Для Nehalem, який є багатопроцесорною платформою, процесори мають можливість "прослуховувати" (підслуховувати) адресну шину для доступу інших процесорів до системної пам'яті та до їх внутрішніх схованок. Вони використовують цю функцію прослуховування, щоб підтримувати свої внутрішні кеші як із системною пам'яттю, так і з кешами в інших взаємопов'язаних процесорах. Якщо через прослуховування одного процесора виявиться, що інший процесор має намір записати в місце пам’яті, яке він наразі кеширував у загальному стані, процесор, який провіряє, буде недійсним блоком кешу, змушуючи його виконувати заповнення рядка кеша наступного разу, коли він отримує доступ до того самого місця пам'яті .
oracle hotspot jdk для x86 архітектури процесора->
lazySet == unsafe.putOrderedLong == xchg rw (інструкція asm, яка служить м'яким бар'єром вартістю 20 циклів на nehelem intel cpu)
на x86 (x86_64) такий бар'єр набагато дешевший, ніж мінливий або AtomicLong getAndAdd,
У сценарії одного виробника, однієї черги споживачів, xchg м'який бар'єр може змусити рядок кодів перед lazySet (послідовність + 1), щоб поток виробника відбувся ПЕРЕД будь-яким кодом споживача, який буде споживати (працювати над) новими даними, звичайно споживчий потік повинен буде атомно перевірити, чи послідовність виробника нарощена рівно на одну, використовуючи порівнянняAndSet (послідовність, послідовність + 1).
Я простежив за вихідним кодом Hotspot, щоб знайти точне відображення коду lazySet на cpp:
http://hg.openjdk.java.net/jdk7/jdk7/hotspot/file/9b0ca45cd756/src/share/vm/prims/unsafe. cpp
Unsafe_setOrderedLong -> SET_FIELD_VOLATILE визначення -> OrderAccess: release_store_fence. Для x86_64, OrderAccess: release_store_fence визначається як використання інструкції xchg.
Ви можете побачити, як це точно визначено в jdk7 (doug lea працює над новими новинками для JDK 8):
http://hg.openjdk.java.net/jdk7/jdk7/hotspot/file/4fc084dac61e/src/os_cpu/ linux_x86 / vm / orderAccess_linux_x86.inline.hpp
ви також можете використовувати hdis для того, щоб розібрати збірку коду lazySet в дії.
Є ще одне пов'язане питання:
чи потрібна нам mfence під час використання xchg