Czy w niektórych wyrażeniach JIT może się załamać dwa lotne odczyty jako jeden?

W mojej pierwotnej odpowiedzi, argumentowałem przeciwko legalności sugerowanej optymalizacji. Poparłem to głównie z informacji z JSR-133 cookbook gdzie stwierdza, że volatile read nie może być zmieniany z innym volatile read i gdzie dalej stwierdza, że odczyt w pamięci podręcznej ma być traktowany jako zmiana kolejności. To ostatnie stwierdzenie jest jednak sformułowane z pewną dwuznacznością, dlatego przeszedłem przez formalną definicję JMM gdzie nie znalazłem takiego wskazania. Dlatego chciałbym teraz argumentować, że optymalizacja jest dozwolona. Jednak JMM jest dość złożony i dyskusja na tej stronie wskazuje, że ta sprawa narożna może być rozstrzygnięta inaczej przez kogoś z bardziej dogłębnym zrozumieniem formalizmu.

Oznaczanie wątku 1 do wykonania

while (true) {
  System.out.println(a // r_1 
    + a); // r_2
} 

I wątek 2 do wykonania:

while (true) {
  a = 0; // w_1
  a = 1; // w_2
}

Dwa odczyty r_i i dwa zapisy w_i z a to synchronizacja działania jako a to volatile (JSR 17.4.2). Są to działania zewnętrzne jako zmienna {[4] } jest używana w kilku wątkach. Akcje te są zawarte w zbiorze wszystkich akcji A. Istnieje całkowita kolejność wszystkich działań synchronizacji, kolejność synchronizacji, która jest zgodna z kolejność programów dla wątek 1 i wątek 2 (JSR 17.4.4). Z definicji synchronizuje-z porządkiem częściowym, nie ma krawędzi zdefiniowane dla tej kolejności w powyższym kodzie. W rezultacie dzieje się-przed kolejnością odzwierciedla tylko semantykę wewnątrz wątku każdego wątku (JSR 17.4.5).

Z tym definiujemy W jako funkcja zapisu widzianego gdzie W(r_i) = w_2oraz funkcja zapisu wartości V(w_i) = w_2 (JLS 17.4.6). Wziąłem trochę swobody i wyeliminowałem w_1, ponieważ to czyni ten zarys formalnego dowodu jeszcze prostszym. Pytanie dotyczy tego proponowanego wykonania E jest dobrze uformowany (JLS 17.5.7). Proponowane wykonanie E jest zgodne z semantyką wewnątrz wątku, dzieje się-przed spójnym, jest zgodne-z porządkiem i każdy odczyt przestrzega spójnego zapisu. Sprawdzenie wymagań dotyczących przyczynowości jest trywialne (JSR 17.4.8). Nie rozumiem też, dlaczego Zasady dla niekończących się egzekucji byłyby istotne, ponieważ pętla obejmuje cały omawiany kod (JLS 17.4.9) i nie musimy rozróżniać obserwowalnych działań.

Dla wszystko to, nie mogę znaleźć żadnych wskazówek, dlaczego ta optymalizacja byłaby zabroniona. Niemniej jednak, nie jest on stosowany do odczytu volatile przez maszynę wirtualną HotSpot, jak można zaobserwować przy użyciu -XX:+PrintAssembly. Zakładam, że korzyści z wykonania są jednak niewielkie i ten wzór nie jest normalnie przestrzegany.

Uwaga: po obejrzeniuJava memory model (wiele razy), jestem prawie pewien, że to rozumowanie jest poprawne.

Trochę zmodyfikowałem problem OP

   volatile int a

    //thread 1
    while (true) {
        a = some_oddNumber;
        a = some_evenNumber;
    }

    // Thread 2 
    while (true) {
        if(isOdd(a+a)) {
            break;
        }
    }

Jeśli powyższy kod został wykonany sekwencyjnie, to istnieje poprawne sekwencyjne wykonanie, które złamie pętlę thread2 while .

Natomiast if kompilator optymalizuje a + a do 2a wtedy thread2 while loop nigdy nie będzie istniał .

Tak więc powyższa optymalizacja zabroni jednej konkretnej realizacji, gdyby była ona wykonywana sekwencyjnie.

Głównym pytaniem jest ta optymalizacja to Problem ?

Q.   Is the Transformed code Sequentially Consistent.

Ans. program jest poprawnie zsynchronizowany, Jeśli, gdy jest wykonywany w spójny sposób sekwencyjnie, nie ma wyścigów danych. Zobacz przykład 17.4.8-1 z JLS Rozdział 17

   Sequential consistency: the result of any execution is the same as
   if the read and write operations by all processes were executed in
   some sequential order and the operations of each individual
   process appear in this sequence in the order specified by its
   program [Lamport, 1979].

   Also see http://docs.oracle.com/javase/specs/jls/se7/html/jls-17.html#jls-17.4.3

Sekwencyjna spójność jest silną gwarancją. Ścieżka wykonania, w której kompilator optymalizuje a + a jako 2a, jest również poprawnym sekwencyjnie spójnym wykonaniem . Więc odpowiedź brzmi: tak.

  Q.   Is the code violates happens before guarantees.

Ans. Konsystencja Sekwencyjna oznacza to, że dzieje się to przed gwarancją jest ważna tutaj . Więc odpowiedź brzmi: tak. JLS ref

więc nie sądzę, aby optymalizacja była nieważna prawnie przynajmniej w przypadku OP. Przypadek, w którym Thread 2 while loops stacza się w nieskończoność, jest również całkiem możliwy bez transformacji kompilatora.

Z jednej strony celem ulotnego czytania jest to, aby zawsze było świeże z pamięci.

Tak nie definiuje specyfikacja języka Java. JLS po prostu mówi:

Zapis do zmiennej lotnej v (§8.3.1.4) synchronizuje-z wszystkie kolejne odczyty v przez dowolny wątek (gdzie "następny" jest zdefiniowany zgodnie z porządkiem synchronizacji).

Dlatego zapis do zmiennej lotnej happens-before (and is visible to) any next reads of that same variable.

To ograniczenie jest trywialnie spełnione dla odczytu, który nie jest późniejszy. Oznacza to, że lotność zapewnia widoczność zapisu tylko wtedy, gdy odczyt jest znany po zapisie.

Tak nie jest w twoim programie. Dla każdego dobrze uformowanego wykonania, które obserwuje a do 1, Mogę skonstruować kolejne dobrze uformowane wykonanie, gdzie A jest obserwowane do 0, po prostu przesuwać odczyt po pisz. Jest to możliwe, ponieważ relacja happens-before wygląda następująco:

write 1   -->   read 1                    write 1   -->   read 1
   |              |                          |              |
   |              v                          v              |
   v      -->   read 1                    write 0           v
write 0           |             vs.          |      -->   read 0
   |              |                          |              |
   v              v                          v              v
write 1   -->   read 1                    write 1   -->   read 1                 

Oznacza to, że wszystkie gwarancje JMM dla Twojego programu są takie, że a + a da 0, 1 lub 2. Jest to spełnione, jeśli a + a zawsze daje 0. Podobnie jak system Operacyjny może wykonać ten program na jednym rdzeniu i zawsze przerwać wątek 1 przed tą samą instrukcją pętli, JVM może ponownie użyć wartości - w końcu obserwowalne zachowanie pozostaje takie samo.

Ogólnie, przenoszenie odczytu przez zapis narusza dzieje się-przed konsystencją, ponieważ inna akcja synchronizacji jest"w drodze". W przypadku braku takich pośrednich działań synchronizacji, Lotny odczyt może być spełniony z pamięci podręcznej.

Jak podano w innych odpowiedziach są dwa odczyty i dwa zapisy. Wyobraź sobie następujące wykonanie (T1 i T2 oznaczają dwa wątki), używając adnotacji zgodnych z instrukcją JLS poniżej:

• T1: a = 0 //W(r)
• T2: read temp1 = a //r_initial
• T1: a = 1 //w
• T2: read temp2 = a //r
• T2: print temp1+temp2

W środowisku współbieżnym jest to zdecydowanie możliwe przeplatanie wątków. Twoje pytanie brzmi: czy JVM będzie mógł wykonać r obserwować W(r) i czytać 0 zamiast 1?

JLS #17.4.5 stwierdza:

Zachodzi zbiór akcji A-przed spójnością, jeśli dla wszystkich odczytów r W A, gdzie W (r) jest akcją zapisu widzianą przez r, nie jest tak, że albo hb(r, W(R)), albo że istnieje zapis w w taki, że w.V = r.V i hb(w(R), w) i hb (w, r).

Zaproponowana optymalizacja (temp = a; print (2 * temp);) naruszyłaby ten wymóg. Tak więc optymalizacja może działać tylko wtedy, gdy między r_initial i r, których nie można zagwarantować w typowym wielowątkowym frameworku.

Jako komentarz boczny, zauważ jednak, że nie ma gwarancji, jak długo potrwa, zanim zapisy staną się widoczne z wątku czytania. Zobacz na przykład: szczegółowa semantyka lotności dotycząca terminowości widoczności .