0:37 - Concurrency - конкуретное выполнение 3:00 - Где мы можем получить выгоду от concurrency? 4:52 - Где мы НЕ можем получить выгоду от [увеличения] concurrency? 5:48 - Закон Амдала (Amdahl's law) 6:56 - Амдал: Поведение (Граф) 8:02 - На самом деле, все еще хуже! 9:35 - USL: Поведение 11:20 - Промежуточный вывод 12:38 - Часть 1. Зачем нужна и как достигается синхронизация 13:05 - Многопоточность в Java (с самой первой версии!) 14:50 - Запуск параллельных вычислений через Thread API 16:22 - Проблемы с shared state 16:39 - Race condition 18:55 - Stale values 22:05 - Reordering 24:10 - Промежуточные выводы. 26:30 - Модель памяти 27:39 - Happens-before 28:48 - Program order rule 29:32 - Thread start & thread terminate rule 30:59 - Ключевое слово volatile 33:27 - Чиним stale value при помощи volatile 34:29 - final-поля 38:10 - Неатомарные операции: final не годится, volatile не спасет 40:25 - Что же делать? Синхронизированное выполнение 42:19 - Блокировки 44:15 - JMM Monitor Lock Rule 45:24 - В чем проблема здесь? 46:24 - В чем проблема здесь? 47:29 - Condition Objects 51:41 - Condition Objects: что происходит? 52:42 - Контрольный вопрос 53:11 - Правильный паттерн ожидания condition 53:38 - Intrinsic lock 54:16 - То же самое, с помощью intrinsic lock 56:39 - Synchronized-блок 58:52 - Промежуточный итог по intrinsic conditions 1:00:17 - Теперь нам понятен смысл всех возможных состояний треда 1:01:48 - Промежуточный итог по всему вышесказанному 1:03:45 - Часть 2. Deadlocks 1:03:51 - Deadlock: простой пример 1:05:09 - Перепутанный порядок блокировки 1:06:05 - Перепутанный (иногда!) порядок блокировки 1:08:10 - Выводы
Привет тому, кто читает этот комментарий. Это таймкоды, которые я ставил для себя, когда разбирал лекции. Я решил поделиться ими со всеми. Возможно они кому-то помогут. Спасибо за внимание.
Здравствуйте.У меня вопрос насчет volatile В разных источниках пишут еще пару вещей насчет этого,которых в вашей лекции не было 1)Оно гарантирует порядок операций.Имеется ввиду,что Jit-компилятор в целях оптимизации может поменять местами операции 2)Делает атомарными операции чтения и записи для Double и Long на 32 разрядных системах Верно ли это все?ПРосто в одних источниках пишут одно,а в других - другое
1. Ну формулировка "Jit-компилятор в целях оптимизации может поменять местами операции" не имеет отношения к реальности, JIT ничего не меняет. Речь идёт о наблюдаемом изменении порядка операций из-за эффектов кэша и оптимизаций в процессоре. Доступ к volatile переменным действительно гарантирует так называемый happens-before порядок (кажется в лекциях я раскрываю определение happens-before порядка), но полагаться на этот эффект использования volatile --плохая практика (опять же, в лекции я где-то я об этом говорю и поясняю почему). 2. Да, это действительно так, хотя в наше время 32-разрядную систему поискать ))
Вот, вы говорили, что таким примитивным способом мы не будем создавать блокировки для частей кода. Но, не могу я оставить всё как есть! Я не понимаю, когда необходимо использовать для блокировки класс ReentrantLock, когда код надо синхронизировать код с помощью this-объекта, переданного в synchronized блок, а когда с помощью независимого объекта Object. Если вас не затруднить, объясните пожалуйста.
В книге Хростманна говорится, если я правильно понял, что ReentrantLock используется, когда необходимо несколько Condition в синхронизированном блоке кода, а в противном случае можно обойтись synchronized блоком. Но на вторую часть вопроса я не знаю ответа, хоть я и искал ответ на этот вопрос, но чёткой разницы я не смог уловить.
На сколько я понял из приведённого примера, блокировка с помощью внешнего Object предпочтительней тогда, когда мотитор this может быть захвачен где-то ещё, но при этом смысл текущей блокировки лишь в том, что бы обеспечить атомарность какай-то оперции не завязанной на this.
