Привет всем! Открываю эту тему для всех, кому она не "параллельна"   
Поддержите своими знаниями? Итак...

Мотивация Изучение параллельных процессов, знакомство с основными концептами синхронизации.
Для начала несколько определений:

Параллельные процессы – это логически не взаимосвязанные действия системы, происходящие одновременно.

Программу можно представить себе, как инструкцию по сборке компьютерного стола.

Если её не прочитать, никогда не узнаешь, почему шурупов всегда меньше чем предназначенных для них дыр. 
Инструкция не действует если её не исполнить. В нашем случае эта инструкция  находятся в .java файле. 
Она переводится в в байт - код, и размещается в файле .сlass.  Исполняется программа с помощью Java Virtual Machine.

Процесс -это компьютерный зал, а Thread - это один или несколько программистов в зале.

Они собирают компьютерный стол. Причём собирать можно либо по общей, либо по своей собственной инструкции. 
Программисты делят между собой отвёртки, дрель, пилу и другие обьекты в компьютерном зале. 

Возникает необходимость регулировать доступ к общим обьектам, и разрешения основной проблемы программирования с Threads - разумного ограничения параллельности.

Псевдопараллельность.  В системах с одним CPU физически возможны только квази – или  псевдопараллельные процессы, которые реализуются путём быстрого переключения с одного процесса на другой.

Реально - параллельные  процессы имеют место в системах с несколькими CPU.

Продолжение следует...

 

Причем тут Java? 

Неожиданный вопрос. Программирование при помощи параллельных процессов - Тредов 
имеет прямое отношение к языку Java. 
К тому же по моему мнению проблематика обьясняется лучше всего Java кодом.

Все примеры которые я приведу будут иметь либо производную от класса Thread, 
либо имплементировать интерфейс Runnable. 




 

Ладно, пофлужу из опыта   

В Java мониторы кривые. По определению (как Hoar'а так и Lampson'а и Redell'a) монитор имеет общий эксклюзивный вход и некоторое количество условных переменных (очередей ожидания). Удобно,  можно реализовать практически любой синхронизационный механизм (ожидание по условию). Напомню что ожидая условной перменной тред сбрасывает блокировку с входа, так что другой тред может войти и уведомить спящий тред.

В Java же монитор не может иметь более одной синхронизационной переменной, т.к. только до неё и получаем эксклюзивный доступ:



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



И тут узнаём что по wait освободиться только a_condition_variable, блок на shared_variables снят не будет. Естественно тот кто должен уведомить a_condition_variable не сможет войти, т.к. ему потребуються общие переменные, которые уже навечно закрыты. Класический deadlock, который два месяца назад ввёл меня в ступор. Даже предположить такого не мог, думал по wait все блокировки отпускаються. Потерял 6 часов рабочего времени   

В итоге: мониторы в Java есть урезанный, не очень удобный механизм синхорнизации, близко не стоящий с "реальными" мониторами.  

P.S. конечно с примитивами синхорнизации можно не заморачиваться, пользуясь java.util.concurrent, но иногда требуеться. В  итоге приходиться сильно извращаться, требуя гораздо больше блокоровок и перетасовок состояниями чем это нужно. 

Спасибо, Sardar! Продолжаем флудить  Я думаю, это принесёт пользу.

Для начала к примеру 



Каждый обьект в Java можно поставить на ожидание в очередь. Это делает метод wait().
Обьекты в очереди должны быть когда - нибудь освобождены из неё методом notify() или notifyAll().

Но wait нужно применять только на обьект который заблокирован в synchronized в данное время.
Это в примере и делается. Но снятие с wait относится только к одному обьекту, 
все остальные остаются блокированными. (В этом случае дело именно в wait, не в synchronized).

Кстати, если один тред нотифицировал ждущего в очереди другого, то тот кто ждал должен сначала снова заблокировать обьект. 

Я имел в виду другое, монитор существует для обьекта в целом, т.к. условные переменные (в Java это обычные обьекты, т.к. все обьекты имеют wait) пользуються общей инфой, что бы вычислить своё состояние и соответствено ждать/уведомлять. Следовательно нужен эксклюзивный доступ, что бы левый тред инфу не убил (например при переборе списка кто то удалил обьект под "курсором"). Но! что бы получить доступ до условной переменной тоже потребуеться эксклюзивный доступ, просто потому что таков дизайн Java. При вызове wait блок с условной переменной снимаеться, а эксклюзивный блок вообще с обьекта (логический обьект, а не буквально обьект Java  ) не снимаеться. В итоге уснуть может только один тред, все остальные, включая тех кто "будит спящих", блокируються на входе (shared_variables). Это прямое не соответствие определению монитора, хотя может сановцы своё определение имеют и workaround'ы для людей со стандартным мышлением   

Перечитал несколько раз  Обнаружил что слишком привык к Java - обьектам и к реальным возвращался с большим трудом    
Потом спросил преподавателя.  Его мнение - концепт сановцев монитору не противоречит, поскольку монитор (нельзя/ненужно?) закладывать внутрь монитора. Пойду еще почитаю для общего развития...

 

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

• пришёл новый обьект, допустим в некую очередь - все кто спал на этой переменной должны проснуться
• все обьекты кончились - также все должны проснуться кто спал на этой перменной

При этом и первая и вторая группа тредов изменяют очередь. Следовательно очередь нужно заблокировать на эксклюзивный доступ или вести несколько экземпляров очередей, что время от времени merge в некую общую. Так вот как освободить очередь если мы засыпаем не на очереди, а на условной переменной. Почему? Да  потому что условия два, а ресурс (очередь) одна. Заставлять всех спать на одной очереди и просыпаться с любого условия крайне глупо и не эффективно. Вот и получилась проблема: как освободить очередь?

Попытался обьяснить как мог, если не понятно, то только одно - пиши софт, когда упрёшся в проблему, поймёшь