Как выполняется переписывание текущей переменной потока в ReentrantLock.Sync?

Question

Я читал о некоторых деталях реализации ReentrantLock в «Java Параллелизм на практике», раздел 14.6.1, и что-то в аннотации заставляет меня путать:

Поскольку защищенные методы государственной манипуляции имеют семантика памяти волатильного чтения или записи и ReentrantLock осторожно, чтобы читал поле владельца только после вызова getState и написал его только до вызова setState, ReentrantLock может копировать в семантику памяти состояния синхронизации и, таким образом, избегать дополнительной синхронизации. Раздел 16.1.4.

код, который он ссылается на:

protected boolean tryAcquire(int ignored) { 
    final Thread current = Thread.currentThread(); 
    int c = getState(); 
    if (c ==0) { 
     if (compareAndSetState(0, 1)) { 
      owner = current; 
      return true; 
     } 
    } else if (current == owner) { 
     setState(c+1); 
     return true; 
    } 
} 

И я считаю, что это упрощенный код nonfirTryAcquire в ReentrantLock.Sync.

final boolean nonfairTryAcquire(int acquires) { 
    final Thread current = Thread.currentThread(); 
    int c = getState(); 
    if (c == 0) { 
     if (compareAndSetState(0, acquires)) { 
      setExclusiveOwnerThread(current); 
      return true; 
     } 
    } 
    else if (current == getExclusiveOwnerThread()) { 
     int nextc = c + acquires; 
     if (nextc < 0) // overflow 
      throw new Error("Maximum lock count exceeded"); 
     setState(nextc); 
     return true; 
    } 
    return false; 
} 

Итак, озадачивает часть, как установка owner, которая является всего лишь обычная переменная экземпляра в AbstractOwnableSynchronizer, становится видимым else if (current == owner) в других потоках. Действительно, чтение owner происходит после вызова getState() (а state - это volatile квалифицированная переменная AQS), но после установки owner ничего нет (можно установить семантику синхронизации). Происходит гонка данных?

Ну, в свете власти этой книги и тщательно протестированного кода, две возможности прийти на ум:

1. The полный барьер (будь то mfence или «lock'ed инструкцию) до настройка owner = current делает скрытую работу. Но из того, что я узнал из нескольких известных статей, полный барьер больше заботится о писаниях перед ним, а также о чтениях после него. Ну, если эта возможность верна, то некоторые предложения в «JCIP» могут быть неправильно указаны.

2. Я заметил, что «географически» setState(c+1) действительно приходит после owner = current в фрагменте кода, хотя он находится в другой ветке if-else. Если, как говорят комментарии, это правда, означает ли это, что барьер, вставленный setSate(c+1), может наложить семантику синхронизации на owner = current в другую ветку?

Я новичок в этой области, а также несколько больших блоги мне очень помогают в понимании того, что никогда, лежащей в основе виртуальной машины Java (без заказа):

• http://mechanical-sympathy.blogspot.com/
• http://preshing.com/
• http://bartoszmilewski.com
• http://psy-lob-saw.blogspot.com/

, а также всегда великолепный: http://g.oswego.edu/dl/jmm/cookbook.html

После выполнения домашней работы и поиска в Интернете я не могу прийти к удовлетворительному выводу.

Простите меня, если это слишком многословно или неясно (английский не мой родной язык). Пожалуйста, помогите мне в этом, все, что связано, оценено.

Answer 1

Вы подозреваете, что может быть гонка между owner = current; (после CAS) и if (current == owner) (после считывания состояния и проверки, если оно> 0).

Принимая этот фрагмент кода в изоляции, я думаю, что ваши рассуждения верны. Тем не менее, вы должны рассмотреть tryRelease, а также:

123:   protected final boolean tryRelease(int releases) { 
124:    int c = getState() - releases; 
125:    if (Thread.currentThread() != getExclusiveOwnerThread()) 
126:     throw new IllegalMonitorStateException(); 
127:    boolean free = false; 
128:    if (c == 0) { 
129:     free = true; 
130:     setExclusiveOwnerThread(null); 
131:    } 
132:    setState(c); 
133:    return free; 
134:   } 

Здесь владелец устанавливается на null перед государством устанавливается в 0. Чтобы сначала получить блокировку, государство должно быть 0, и поэтому владелец null ,

Следовательно,

• Если поток достигает if (current == owner) с c=1,
  • может быть владеющей нитью, и в этом случае владелец правильно и состояние увеличивается.
  • это может быть другой поток, который может видеть или не новый владелец.
    • Если он видит это, все в порядке.
    • Если нет, он увидит null, что тоже хорошо.
• Если поток достигает if (current == owner) с c>1,
  • может быть владеющей нитью, и в этом случае владелец правильно и состояние увеличивается.
  • это может быть другой поток, но владелец будет верным.

Я aggree, что сноска «читать поле владельца только после вызова GetState и писать только перед вызовом SetState» в JCIP вводит в заблуждение. Он пишет owner перед вызовом setState в tryRelease, но не tryAcquire.

Answer 2

Это хорошо объясняется в this blog post. Итог заключается в том, что, когда поток чтения считывает изменчивое поле, все поля, обновленные потоком записи, которые были изменены перед записью в поле volatile, также будут видны в потоке чтения. Класс блокировки организует поле обращается для того, чтобы только состояние поля должно быть неустойчивым, а поле владельца еще безопасно propogated при необходимости