anchor.diff:  === *Перечислите все сценарии выхода из wait-set встроенного монитора*
   
   * Другой поток, держа монитор, вызвал метод `notify` или `notifyAll` на объекте
  -* Если поток попал в список ожидания вызывом `wait` c таймаутом, то по
  -истечении таймаута поток проснется
  +* Если поток попал в список ожидания вызывом `wait` c таймаутом, то по истечении таймаута поток проснется
   * Поток, попавший в список ожидания, прерван вызывом `Thread.interrupt`
  -* Поток может проснуться без видимой на то причины. ОС не запрещено это делать.
  -Это называется *spurious wakeup*
  +* Поток может проснуться без видимой на то причины. ОС не запрещено это делать. Это называется *spurious wakeup*
   
   === *Различия между Thread.isInterrupted() и Thread.interrupted()?*
   
  -`Thread.isInterruped()` является обычным методом, возвращает значение флага
  -прерывания и не изменяет его. В то время как `Thread.interrupted()` является
  -статическим методом, возвращает значение и устанавливает флаг в `false`.
  -
  -Трудно представить случай, когда следует использовать второй метод.
  +`Thread.isInterruped()` является обычным методом, возвращает значение флага прерывания и не изменяет его. В то время как `Thread.interrupted()` является статическим методом, возвращает значение и устанавливает флаг в `false`.Трудно представить случай, когда следует использовать второй метод.
   
   === *Расскажите о идиоме многопоточного проектирования Private mutex*
   
  -Идея в том, объект содержит в себе в примитив синхронизации - бинарный семафор
  -или мьютекс. С помощью мьютекса можно создавать критические секции. Каждый
  -поток обязан захватить мьютекс при входе и отпустить его при выходе. Так как
  -мьютекс приватный, то мы можем гарантировать, что его будут использовать только
  -потоки, которые работают с объектом.
  +Идея в том, объект содержит в себе в примитив синхронизации - бинарный семафор или мьютекс. С помощью мьютекса можно создавать критические секции. Каждый поток обязан захватить мьютекс при входе и отпустить его при выходе. Так как мьютекс приватный, то мы можем гарантировать, что его будут использовать только потоки, которые работают с объектом.
   
   === *Расскажите о идиоме многопоточного проектирования Spin lock/Busy waiting*
   
  -Подход состоит в том, что в ситуации когда поток обнаруживает, что определенное
  -условие еще не наступило и он не может продолжать
  -свою работу, он вместо того, чтобы переходить в режим ожидания, пытается
  -крутиться в цикле, проверяя условие.
  -
  -Идея в том, что если условие очень быстро меняется, то более разумно немного
  -подождать в user-mode и жечь циклы процессора, чем переходить в тяжелый режим
  -ожидания. Если на мониторе большая конкуренция, то мы не будем тратить время на
  -накладные расходы по подъему и опусканию потоков, а выполнять операции быстрее,
  -тратя в обмен на это процессорные ресурсы.
  +Подход состоит в том, что в ситуации когда поток обнаруживает, что определенное условие еще не наступило и он не может продолжать свою работу, он вместо того, чтобы переходить в режим ожидания, пытается крутиться в цикле, проверяя условие. Идея в том, что если условие очень быстро меняется, то более разумно немного подождать в user-mode и жечь циклы процессора, чем переходить в тяжелый режим ожидания. Если на мониторе большая конкуренция, то мы не будем тратить время на накладные расходы по подъему и опусканию потоков, а выполнять операции быстрее, тратя в обмен на это процессорные ресурсы.
   
   === *Расскажите о идиоме многопоточного проектирования backoff protocol (expotential backoff)*
   
  -Подход основывается на наблюдении о том, что когда несколько потоков
  -одновременно запрашивают разделяемый ресурс и повторяют попытки в случае
  -неудачи, то большинство запросов являются "холостыми", т.к. у ресурса
  -слишком большая очередь потенциальных потребителей. Когда все потоки
  -одновременно пытаются захватить ресурс - выигрывает только один. Остальным
  -приходится опять повторять запросы. В итоге много процессорного времени
  -тратится на бесполезную работу.
  -
  -Одним из решением этой проблемы является backoff. Каждый поток после неудачи
  -засыпает на случайный промежуток времени. Если распределение времени сна
  -хорошее, то когда поток проснется - велика вероятность, что ресурс будет
  -свободен. Таким образом мы "рассасываем" очереди на ресурсе, назначая каждому
  -потоку свое время прихода. Потоки, чья очередь еще не пришла, вместо того,
  -чтобы жечь процессорные циклы - спят.
  -
  -_Expotential backoff_ - это протокол отката, по которому величина промежутка
  -времени ожидания, из которого оно случайно выбирается, увеличивается в
  -зависимости от количества неудачных попыток. Идея заключается в том, чтобы
  -использовать количество отказов как эвристику для поиска оптимального времени
  -ожидания. Чем больше неудач, тем шире нужно брать окно, чтобы уменьшить
  -вероятность коллизий.
  +Подход основывается на наблюдении о том, что когда несколько потоков одновременно запрашивают разделяемый ресурс и повторяют попытки в случае неудачи, то большинство запросов являются "холостыми", т.к. у ресурса слишком большая очередь потенциальных потребителей. Когда все потоки одновременно пытаются захватить ресурс - выигрывает только один. Остальным приходится опять повторять запросы. В итоге много процессорного времени тратится на бесполезную работу. Одним из решением этой проблемы является backoff. Каждый поток после неудачи засыпает на случайный промежуток времени. Если распределение времени сна хорошее, то когда поток проснется - велика вероятность, что ресурс будет свободен. Таким образом мы "рассасываем" очереди на ресурсе, назначая каждому потоку свое время прихода. Потоки, чья очередь еще не пришла, вместо того, чтобы жечь процессорные циклы - спят.
  +
  +_Expotential backoff_ - это протокол отката, по которому величина промежутка времени ожидания, из которого оно случайно выбирается, увеличивается в зависимости от количества неудачных попыток. Идея заключается в том, чтобы использовать количество отказов как эвристику для поиска оптимального времени ожидания. Чем больше неудач, тем шире нужно брать окно, чтобы уменьшить вероятность коллизий.
   
   === *Что это за свойство — «reentrancy»?*
   
  -*Reentrancy(повторное вхождение)* - это свойство блокировки, которое
  -характеризуется тем, что поток, который держит лок, может захватить его
  -сколько угодно раз. То есть это значит, что поток не может заблокироваться
  -на самом себе. 
  -
  -Это очень удобное свойство в ситуации, когда лок защищает несколько методов
  -и эти методы взаимодействуют между собой.
  +*Reentrancy(повторное вхождение)* - это свойство блокировки, которое характеризуется тем, что поток, который держит лок, может захватить его сколько угодно раз. То есть это значит, что поток не может заблокироваться на самом себе. Это очень удобное свойство в ситуации, когда лок защищает несколько методов и эти методы взаимодействуют между собой.
   
   === *Что такое «poison message»?*
   
  -*Poison messsage* - это сообщение, которое не может быть обработано из-за
  -ошибок (скажем, откатившейся транзакции), но продолжает сидеть в очереди и
  -блокировать другие сообщения. Если очередь забьется такими сообщениями, то
  -она перестанет обрабатывать нормальные сообщения и, фактически, прекратит
  -обслуживание.
  -
  -Для предотвращения таких ситуаций в очереди должет быть параметр, который
  -контролирует максимальное количество попыток доставки сообщения.
  +*Poison messsage* - это сообщение, которое не может быть обработано из-за ошибок (скажем, откатившейся транзакции), но продолжает сидеть в очереди и блокировать другие сообщения. Если очередь забьется такими сообщениями, то она перестанет обрабатывать нормальные сообщения и, фактически, прекратит обслуживание. Для предотвращения таких ситуаций в очереди должет быть параметр, который контролирует максимальное количество попыток доставки сообщения.
   
   === *Что такое «mutual exclusion»? Примеры как добиться в Java*
   
  -*Mutual exclusion* - это требования выполнения участка кода только одним
  -процессом/потоком в единицу времени. В этом случае участок кода
  -называется критической секцией. 
  -
  -В Java можно добиться с помощью *synchronized* блока, `ReentrantLock`,
  -семафора с единичной длиной, блокирующей очередью в 1 элемент, spinloop
  -на *volatile* флаге.
  -
  -Возможно, еще CAS (но в этом случае мы говорим не об участке кода, а
  -о ячейке памяти).
  +*Mutual exclusion* - это требования выполнения участка кода только одним процессом/потоком в единицу времени. В этом случае участок кода называется критической секцией. В Java можно добиться с помощью *synchronized* блока, `ReentrantLock`, семафора с единичной длиной, блокирующей очередью в 1 элемент, spinloop на *volatile* флаге. Возможно, еще CAS (но в этом случае мы говорим не об участке кода, а об ячейке памяти).
   
   === *Что такое «condition waiting»? Примеры как добиться в Java*
   
  -Честно говоря, не знаю такого термина. Подозреваю, имеется ввиду ситуация,
  -когда поток обнаруживает ситуацию, в которой он не может продолжить
  -выполнение (скажем, очередь заполнена), он вместо того, чтобы выбросить
  -ошибку, подписывается на нотификацию, отдает лок и ждет пока наступит
  -условие для продолжения (появилось свободное место в очереди). 
  -
  -В Java можно добиться с помощью механизма `wait`/`notify` или класса
  -`Condition` и помощью методов `await`/`signal`.
  +Честно говоря, не знаю такого термина. Подозреваю, имеется ввиду ситуация,когда поток обнаруживает ситуацию, в которой он не может продолжить выполнение (скажем, очередь заполнена), он вместо того, чтобы выбросить ошибку, подписывается на нотификацию, отдает лок и ждет пока наступит условие для продолжения (появилось свободное место в очереди). В Java можно добиться с помощью механизма `wait`/`notify` или класса `Condition` и помощью методов `await`/`signal`.
   
   ==  java.util.concurrent: Пулы потоков, Future
   
   === *Различия в интерфейсах Runnable и Callable*
   
  -Разница заключается в том, что `Callable` дает возможность выполнить 
  -определенный код и вернуть значение, а `Runnable` только выполнить код.
  -
  -Также код в `Callable` может выбросить проверямое исключение, в то
  -время как в `Runnable` этого делать не позволяет. Исключение нужно 
  -оборачивать в непроверямое.
  +Разница заключается в том, что `Callable` дает возможность выполнить определенный код и вернуть значение, а `Runnable` только выполнить код. Также код в `Callable` может выбросить проверямое исключение, в то время как в `Runnable` этого делать не позволяет. Исключение нужно оборачивать в непроверямое.
   
   === *Преимущества ScheduledThreadPool перед java.util.Timer*
   
  
positive.code: 
  === *Говорят, что Future/CompletableFuture — это монада. Что скажете?*
  
  Если упростить до невозможности, то монада - это структура, позволяющая
  представить значение в контексте выполнения операции. 
  
  То есть вместо того, чтобы работать с реальным значением, мы можем 
  представить его контейнером и дальше оперировать контейнером как 
  заместителем реального значения. У контейнера есть операции создания и 
  преобразования в контейнер с другим содержимым. Это позволяет программисту
  в некоторых местах сильно упростить код, когда его не интересуют 
  промежуточное состояние. Он может работать с монадой как с реальным 
  значением, не имея его представления.
  
  `Future` не является классической монадой, так как не позволяет
  преобразовывать себя в другие обещания выполнения. Можно только 
  параметризировать `Future` типом и создать его (например, через 
  `FutureTask`). 
  
  В свою очередь `CompletableFuture` позволяет преобразовывать одни 
  обещания выполнения в другие.
  
negative.code: * MIMD - вычислительные системы с несколькими потоками данных и несколькими
  потоками инструкций (распределенные системы).
  
  Одноядерные процессоры относятся к SISD системам, многоядерные процессоры к SIMD или MIMD. GPU является SIMD системой, потому что использует векторные инструкции для операций над мультимедиа-данными.
  
  === *Расскажите про иерархию кэшей L1/L2/L3? Что вызвало ее появление*
  
  