anchor.diff:  
   * Рефлексивность. Результат самой операции, очевидно, видим и упорядочен для  нее самой.
   
  -* Антисимметричность. Если результат операции *A* видим и упорядочен для операции *B*, то результат операции *B* бы не видим и не упорядочен для *A*.
  -
  -Если бы *B* была бы видна для *A*, это значит, что для ее (*A*) локального времени *B* произошла до *A*. Так как результат *A* виден для *B*, то это значит, что для ее (*B*) локального времени *A* произошла до *B*. Так как отношение "произошел до/был раньше" транзитивно, из этого следует что *B* произшла до *B*. Получаем противоречие. Следовательно, *B* не может быть видна для *A*.
  -
  -* Транзитивность. Если результат операции *A* видим и упорядочен для *B* и результат *B* видим и упорядочен для *C*, то результат *A* видим и упорядочен для *С*.
  -
  -Так как *A* видна для *B*, то она произошла до *B* в ее локальном времени. Так как *B* видима для *C*, то она произошла до *C* в ее локальном времени. Так как отношение "произошел до/был раньше" транзитивно, то и операция *A* видима для *C*.
  +* Антисимметричность. Если результат операции _A_ видим и упорядочен для операции _B_, то результат операции _B_ бы не видим и не упорядочен для _A_.
  +
  +Если бы _B_ была бы видна для _A_, это значит, что для ее (_A_) локального времени _B_ произошла до _A_. Так как результат _A_ виден для _B_, то это значит, что для ее (_B_) локального времени _A_ произошла до _B_. Так как отношение "произошел до/был раньше" транзитивно, из этого следует что _B_ произшла до _B_. Получаем противоречие. Следовательно, _B_ не может быть видна для _A_.
  +
  +* Транзитивность. Если результат операции _A_ видим и упорядочен для _B_ и результат _B_ видим и упорядочен для _C_, то результат _A_ видим и упорядочен для *С*.
  +
  +Так как _A_ видна для _B_, то она произошла до _B_ в ее локальном времени. Так как _B_ видима для _C_, то она произошла до _C_ в ее локальном времени. Так как отношение "произошел до/был раньше" транзитивно, то и операция _A_ видима для _C_.
   
   === *Что такое data-race?*
   
  
positive.code: 
  === *Как сделать Safe Publishing используя AtomicBoolean?*
  
  У `AtomicBoolean` точно же такая семантика как и у _volatile_. Для того, чтобы безопасно опубликовать объект через `AtomicBoolean`, достаточно перед чтением объекта сначала прочитать `AtomicBoolean` переменную, а после изменения записать ее.
  
  === *Что такое Монитор?*
  
  Монитор - объект синхронизации, которым обладает каждый Java-объект. Для того, чтобы войти в критическую секцию, потоку сначала нужно захватить монитор. Если монитор уже захвачен другим потоком, то этот поток переходит в состояние **BLOCKING**. После того как поток выходит из критической секции, он отпускает монитор. Также мониторы имеют встроенный механизм ожидания и пробуждения на определенных условиях. При переходе в режим ожидания поток попадает в wait-set монитора и другой поток может пробудить его после наступления условия. Наличие монитора у каждого объекта позволяет не использовать внешние мьютексы, а организовывать критическую секцию с помощью конструкции языка synchronized, которая по умолчанию использует монитор текущего объекта.
  
  === *Расскажите о взаимодействии synchronized/Object.wait()/.notify()/.notifyAll()*
  
  Каждый монитор имеет механизм ожидания и пробуждения. После того как поток захватил монитор, он может обнаружить, что условие для продолжения работы еще не наступило (скажем, данные еще не готовы). В этом случае хочется не постоянно проверять условие (при этом отпуская и захватывая монитор, чтобы дать другому потоку шанс изменить состояние условия), а уснуть, отдать монитор и получить нотификацию, когда условие будет выполнено. Эта функциональность достигается с помощью методов `wait`, `notify` и `notifyAll`. После того как поток захватил монитор и вошел в критическую секцию, организованную с помощью `synchronized`, он может вызывать метод `wait`. В этом случае он перейдет в wait-set монитора и отпустит монитор. При этом поток заблокируется и перейдет в состояние **WAITING**. Другой поток может захватить монитор и войти в критическую секцию, выполнить определенные действия и вызвать метод `notify` или `notifyAll`. После того как один из этих методов вызван, поток ждущий на событие, удаляется из wait-set монитора и переходит в состояние **BLOCKING** и пытается захватить монитор. После того, как поток, который вызвал `notify` освобождает монитор, блокирующий поток захватывает монитор и переходит в состояние **RUNNABLE**.
  
  `notify` от `notifyAll` отличается тем, что первый пробуждает один из потоков в списке ожидания, в тоже время как последний пробуждает все потоки. Почти всегда более разумно всегда вызывать `notifyAll`, т.к. вызов этого метода дает шанс всем потокам получить монитор и он работает правильно в независимости от количества потоков в списке ожидания.
  
  
negative.code: 
  === *Атомарно ли ++ для volatile переменной?*
  
  Нет, так как в реальности ++ представляет из себя 3 инструкции: чтение, инкремент и запись. volatile гарантирует только атомарность одиночной записи (мы не увидим шум внутри поля), но не атомарность набора операций. То есть никто не запрещает 2 процессам прочитать одинаковое значение переменной, сделать инкремент и записать его в память. В этом случае мы получим "потерянную запись". 
  
  ==  Базовое API, примитивы/конструкции
  
  === *Thread.getState() возвращает экземпляр Thread.State. Какие возможны значения?*
  
  * `NEW` - поток был создан, но еще не стартовал; 
  * `RUNNABLE` - поток выполняется. Этот статус не обязательно значит, что поток выполняет код. Это всего лишь значит, что поток доступен планировщику потоков для выбора потока на исполнение;
  * `WAITING` - поток ждет на мониторе; Поток переходит в него вызовами методов  `wait()`, `join()` либо парковкой через `LockSupport.park()`
  * `TIME_WAITING` - поток ждет на мониторе с таймаутом; Те же самые методы, только  с таймаутом + `sleep`.
  * `BLOCKED` - поток заблокирован на мониторе; Поток переходит в него когда пытается войти в критическую секцию, но она уже занята другим потоком. 
  * `TERMINATED` - поток завершил выполнение. 
  
  === *Отличие Thread.start() и Thread.run()?*
  
  