>рабочие заметки: Квест по внутренностям JMM

13 февраля 2013 г.

Квест по внутренностям JMM

class AtomicInteger { private volatile int value; public AtomicInteger(final int value) { this.value = value; } .... }
AtomicInteger sharedRef;
Thread 1	Thread 2
sharedRef = new AtomicInteger(42);	if( sharedRef != null ) { System.out.println(sharedRef.get()); }

class AtomicInteger { 
    private volatile int value;
    public AtomicInteger(final int value) {
        this.value = value;
    }
....
}

AtomicInteger sharedRef;

Thread 1

Thread 2

sharedRef = new AtomicInteger(42);

if( sharedRef != null ) {
    System.out.println(sharedRef.get());
}

Может ли этот код вывести 0?
...Если может — то как? ~~Сможете ли вы теперь теми же глазами смотреть на AtomicInteger?~~
...Если нет — то почему?

P.S. Я, если честно, точного ответа не знаю. Хотя пара правдоподобных вариантов у меня есть.

45 комментариев:

Yury Vasyutinskiy13 февраля 2013 г. в 14:21
Если, не ошибаюсь, то из-за того что sharedRef не volatile, т.е. запись ссылки и её чтение не связаны никакими ребрами happens before, а value не объявлен как final, то есть вероятность того, что второй поток увидит ссылку на sharedRef, но вот поле value всё ещё будет содержать defaultValue, т.е. 0. И да, тут скорее конечно надо другими глазами не на AtomicInteger смотреть, а на new.
ОтветитьУдалить
Ответы
Unknown13 февраля 2013 г. в 20:01
Я, думаю, что мы никодгда не получил ноль, только если пометим поле sharedRef как final. По крайней мере я всегда стараюсь так делать, когда с атомиками работаю, мне почему-то так спокойнее %)

Кстати, а почему в твоем примере поле констуктора final? Вроде в моих сорсах оно так не помечено. Ты туда его нарошно поставил?
ОтветитьУдалить
Ответы
Unknown13 февраля 2013 г. в 20:14
Ах, да не ответил почему ноль-то можем получить.
Код Thread1 по идее можно переписать так.
localRef = new AtomicInteger();
localRef.value = 42; // volatile store
sharedRef = localRef;
Какие же ограничения нагладываются volatile? Читаем тут один абзац: http://developer.android.com/training/articles/smp.html

Non-volatile accesses may be reorded with respect to volatile accesses in the usual ways, for example the compiler could move a non-volatile load or store “above” a volatile store, but couldn’t move it “below”. Volatile accesses may not be reordered with respect to each other. The VM takes care of issuing the appropriate memory barriers.

Т.е. строочка "sharedRef = localRef;" вполне легально "could move above a volatile store" т.е. сточки "localRef.value = 42" и мы получаем ноль.

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

Вот почему такого эффекта не будет если пометить sharedRef как final, я объяснить не могу. Но я уверен, что JVM, начиная с версии 5.0, сделает все возможное и невозможное, чтобы в случае с final мы никогда не увидели 0.
ОтветитьУдалить
Ответы
Unknown14 февраля 2013 г. в 16:59
safe publication

Thread 2 не может получить ссылку на AtomicInteger до того как он окончательно сконструирован. Конструктор AtomicInteger нигде не утекает ссылками на себя. Поэтому в момент присвоения значение в sharedRef AtomicInteger всегда инициализирован. Ну, а volatile на value гарантирует видимость значения в других потоках.
ОтветитьУдалить
Ответы
Unknown14 февраля 2013 г. в 17:42
В JSR-133 есть такие строки:
A write to a volatile field happens-before every subsequent read of that volatile

не является ли это ответом?
ОтветитьУдалить
Ответы
Vladimir Dolzhenko14 февраля 2013 г. в 18:59
кстати, а вот таки интересный пример из жизни насекомых

CHM:

static final class HashEntry {
final K key;
final int hash;
volatile V value;
final HashEntry next;

HashEntry(K key, int hash, HashEntry next, V value) {
this.key = key;
this.hash = hash;
this.next = next;
this.value = value;
}
}

в CHM, как известно, нельзя положить пару key-null

однако CHM$Segment.get как бы намекает на что-то

/**
* Reads value field of an entry under lock. Called if value
* field ever appears to be null. This is possible only if a
* compiler happens to reorder a HashEntry initialization with
* its table assignment, which is legal under memory model
* but is not known to ever occur.
*/
V readValueUnderLock(HashEntry e) {
lock();
try {
return e.value;
} finally {
unlock();
}
}

/* Specialized implementations of map methods */

V get(Object key, int hash) {
if (count != 0) { // read-volatile
HashEntry e = getFirst(hash);
while (e != null) {
if (e.hash == hash && key.equals(e.key)) {
V v = e.value;
if (v != null)
return v;
return readValueUnderLock(e); // recheck
}
e = e.next;
}
}
return null;
}

О чём это нам хотел сказать Doug Lea ?
ОтветитьУдалить
Ответы
Vladimir Dolzhenko15 февраля 2013 г. в 00:38
Этот комментарий был удален автором.
ОтветитьУдалить
Ответы
Unknown15 февраля 2013 г. в 00:40
Чет у меня подозрение что дело все же в volatile поле. Т.е. переменная sharedRef получит ссылку на объект AtomicInteger когда выполнится конструтор, а так как выполнится конструктор то произойдет запись в volatile поле value. И в итоге получаем hb записи value и чтение. Результат ноль не увидим.
ОтветитьУдалить
Ответы
Sasha19 февраля 2013 г. в 18:57
Ответ: нет не возможно.
Код для пояснения:
public class A {
B bRef;
public static void main(String[] args) {
A a = new A();
a.bRef = new B(a,42);
}
}
class B{
volatile int value;
public B(A a,final int c) {
this.value=c;
//будет null. ссылка ещё не запаблишилась.
System.out.println(a.bRef);
}
}

Запис volatile переменной happens-before паблишинга ссылки на B. Поэтому так зареордериться не сможет.
В итоге если bRef!=null то value уже не 0.
ОтветитьУдалить
Ответы
Valentin Kovalenko14 марта 2014 г. в 13:43
>>ваше объяснение не верно, хотя само утверждение конечно верно
Руслан, неверно ни утверждение, ни ваше доказательство http://cheremin.blogspot.ru/2013/02/jmm-solution.html :)

В вашем доказательстве ошибочно следующее утверждение:
"Поскольку (2) и (6) — synchronized actions, то из ![ (2) sw (6) ] => [(6) sw (2) ] => [(6) hb (2)]"
Ошибочно оно потому, что SW - частичный порядок, и потому из ![ (2) sw (6) ] не следует [(6) sw (2) ]. Единственный полный порядок определяемый JMM - это SO, но ведь тут речь не про него.

Алексей Шипишёв писал на конкаренси интерест аналогичный вопрос (http://cs.oswego.edu/pipermail/concurrency-interest/2013-November/011951.html) со своим обоснованием, где допустил похожую ошибку.
А вот и обоснование возможности прочитать 0, в котором пока никто ошибки не нашёл: http://cs.oswego.edu/pipermail/concurrency-interest/2013-November/011954.html
Кроме того, утверждение, что 0 прочитать возможно, "заверено печатью" Дага Ли:http://cs.oswego.edu/pipermail/concurrency-interest/2013-November/011966.html
ОтветитьУдалить
Ответы

Добавить комментарий

13 февраля 2013 г.

Квест по внутренностям JMM

45 комментариев:

13 февраля 2013 г.