Java Thread - ошибки согласованности памяти - PullRequest
Новая
       13

Java Thread - ошибки согласованности памяти

14 голосов
/ 03 мая 2010

Я читал учебник Sun по параллелизму .

Но я не мог точно понять, что ошибки согласованности памяти ? Я погуглил об этом, но не нашел ни одного полезного учебника или статьи по этому поводу.

Я знаю, что этот вопрос носит субъективный характер, поэтому вы можете предоставить мне ссылки на статьи по вышеуказанной теме.

Было бы здорово, если бы вы объяснили это простым примером.

Ответы [ 5 ]

7 голосов
/ 03 мая 2010

Вы можете прочитать об опасностях Чтение после записи (RAW), Запись после записи (WAW) и Запись после чтения (WAR) , чтобы узнать больше об этой теме.Эти опасности относятся к конвейерным процессам, но на самом деле это та же проблема, которая возникает при многопоточности.По сути, это означает, что два разных потока обновляют одно и то же место в памяти, и если вы зависите от этих обновлений в определенном порядке, вы можете быть удивлены тем, что не можете гарантировать порядок, в котором происходят обновления.Например, если у вас есть два оператора: 

  x = y + z;
  r = x + z;

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

4 голосов
/ 03 мая 2010

В принципе, при отсутствии каких-либо потоков синхронизации можно увидеть другое значение поля simple . Рассмотрим этот пример: 

class Foo
{
  int bar = 0;

  void unsafeCall ( )
  {
    final Foo thisObj = this;

    Runnable r = new Runnable ( )
    {
      public void run ( )
      {
        thisObj.bar = 1;
      }
    }

     Thread t = new Thread(r);

     t.start( );
     Thread.sleep( 1000 );

     // May print bar = 0
     System.out.println( "bar = " + bar );
  }
}

Самый простой способ избежать ошибки согласованности памяти - объявить поле bar равным volatile (подробности см. Здесь: https://www.ibm.com/developerworks/java/library/j-jtp06197/).

Это принуждение потоков перепроверить память называется барьер памяти . Другим примером барьера памяти является synchronized метод / блок.

3 голосов
/ 03 мая 2010

Hm. В основном они говорят о «проблемах видимости» и «проблемах переупорядочения» (эта терминология более распространена, по крайней мере, в Java IMO). Я думаю, что эта ссылка: http://www.cs.umd.edu/~pugh/java/memoryModel/jsr-133-faq.html#volatile объясняет, о чем идет речь в этом руководстве, используя более общие термины (возможно, sun попытался использовать «более простой» словарь или что-то в этом роде).

1 голос
/ 29 февраля 2012

Я нашел хороший пример при поиске этого вопроса. Как показано ниже: 

    Accesses to main memory might not occur in the same
    order that the CPU initiated them, particularly for writes
    (which often go through hardware write buffers so the CPU
    needn't wait for them). If CPU 1 writes the Answer to
    location A and then writes the AnswerIsReady flag to B,
    CPU 2 may see the change to B before it sees the change
    to A, and thus get the WrongAnswer. Making either or both
    writes atomic doesn't help; what's needed is something
    called a "memory barrier."

через http://www.velocityreviews.com/forums/t390825-memory-consistency-errors.html

0 голосов
/ 04 мая 2010

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

http://rsim.cs.uiuc.edu/~sadve/Publications/computer96.pdf

...