![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
singalenКак я провёл лето прочёл Lea.
С вопроса "Что нового узнал" начинается настоящий конспект %)
Новое:
Чётко сформулированы термины параллельности. Их много: в постановке задачи,
в проблематике, в решениях.
Перечисляю:
Exclusion, state dependance,
Три принципа:
Always lock during updates to object fields.
Always lock during access of possibly updated object fields.
Never lock when invoking methods on other objects.
тоже порадовали своей простотой и неполнотой :)
Смутно чувствую, что здесь должна быть более сложная модель, охватывающая гораздо больший диапазон частных случаев - с приватными переменными, thread-specific переменными, и те де, и те пе.
Интересно было почитать о средствах языка, широко применяеммых в параллельном программировании, в частности о слве final. Наверное, есть что-то ещё?
UnmodifiableCollection?
Inner classes are convenient and useful is that they capture all appropriate context variables - here p and canvas - without the need to create a separate class with fields that record these values. This convenience comes at the price of one minor awkwardness: All captured method arguments and local variables must be declared as final, as a guarantee that the values can indeed be captured unambiguously.
Оказывается, вот для чего нужна ThreadGroup - для разделения доступа треда к треду.
Много ссылок на хорошую литературу, читанную и нечитанную.
Чётко перечислены и описаны накладные расходы параллельности: Sharing, Scheduling, Communication.
Оказывается, на Java можно создавать lighter-weight frameworks, если перечисленные свойства Thread становятся проблемой для производительности. Интересно, как.
Первым параллельным языком была Simula.
Я неправильно перевожу "конкурентный" как "параллельный". Параллельный - это когда каждая задача выполняется на своём процессоре и процессы общаются только через сообщения. А конкурентный - это со всеми прелестями именно что конкурентного доступа к переменным, race conditions.
Новое:
Выражение конкурентной системы в противостоянии Инь и Ян... то есть:
Safety. Nothing bad ever happens to an object.
Liveness. Something eventually happens within an activity.
Другие имена великих начал -
Reusability. The utility of objects and classes across multiple contexts.
Performance. The extent to which activities execute soon and quickly.
Далее конкурентное программирование рассматривается с точки зрения Дао... то есть этих аспектов.
Наконец точно узнал, чем чреваты пресловутые race conditions.
Это так-таки всего-навсего два конфликта:есть контакт там, где его не должно быть, и нет контакта там, где он есть Read-Write и Write-Write conflicts (причём, я думаю, Write без предыдущего Read не бывает).
Как часть возможной модели, вводятся варианты атрибутов:
- непосредственное значение;
- кэшированное значение;
- булевское значение, управляющее логикой кода;
- состояние процесса выполнения;
- история предыдущих состояний;
- версия (таймстамп);
- ссылки на объекты, с которым объект общается, но которыми не владеет;
(кстати, кто предложит атрибут, не укладывающийся в эту модель?)
Классификация ошибок/проблем конкурентности.
- locking & waiting, input (проблема ли это?), CPU contention (никогда-не-получение тредом ЦПУ), перманентная thread failure, deadlocks, и nested monitor lockouts (чем они различаются?), missed signals, livelock (вариант дедлока, когда попытки залочить не ждут, а крутятся в цикле), starvation (чем не CPU contention?), resource exhaustion, distributed failure.
Очень хорошая подборка критериев производительности, которая может в какой-то степени ответить на вопрос Сергея о том, как вообще мерить производительность распределённой (т.е. тоже конкурентной/параллельной) системы (за расшифровкой см. книгу ;):
- Throughput;
- Latency;
- Capacity;
- (Resource) Efficiancy;
- Scalability;
- Degradation;
И причины её падения:
- Locks;
- Monitors;
- Threads;
- Context-switching;
- Scheduling;
- Locality;
- Algorithmics.
Подняты проблемы повторного использования. Повторное использование компоненты, даже тред-безопасной самой по себе, может приводить к проблемам с тредами.
Вот ведь как.
Особое внимание в свете конкурентности уделяется инкапсуляции (Restricted external communication) и консистентности (Deterministic internal structure).
В секции "Документирование" подчёркивается важность инвариантов.
Пошло непонятное.
"The fields of any object should preserve all invariants whenever the object is not engaged in a public method"
Но откуда это следует - именно public? Что, в private нельзя записать последовательно в два поля, не лоча их, а в public можно? Ссылка на секцию 1.3.1, "Safety" вопроса не прояснила. Или наоборот, именно публичные методы так-таки обязаны сохранять инварианты только в начале и конце, а остальные не обязаны? (Это более вероятно)
В чём важность именно before/after проверок инвариантов - такая, что ей нужно было посвятить целую главу?
С вопроса "Что нового узнал" начинается настоящий конспект %)
Глава 1.1 Using Concurrency Constructs
Новое:
Чётко сформулированы термины параллельности. Их много: в постановке задачи,
в проблематике, в решениях.
Перечисляю:
Exclusion, state dependance,
Три принципа:
Always lock during updates to object fields.
Always lock during access of possibly updated object fields.
Never lock when invoking methods on other objects.
тоже порадовали своей простотой и неполнотой :)
Смутно чувствую, что здесь должна быть более сложная модель, охватывающая гораздо больший диапазон частных случаев - с приватными переменными, thread-specific переменными, и те де, и те пе.
Интересно было почитать о средствах языка, широко применяеммых в параллельном программировании, в частности о слве final. Наверное, есть что-то ещё?
UnmodifiableCollection?
Inner classes are convenient and useful is that they capture all appropriate context variables - here p and canvas - without the need to create a separate class with fields that record these values. This convenience comes at the price of one minor awkwardness: All captured method arguments and local variables must be declared as final, as a guarantee that the values can indeed be captured unambiguously.
yield() может быть описан как no-op.Оказывается, вот для чего нужна ThreadGroup - для разделения доступа треда к треду.
Много ссылок на хорошую литературу, читанную и нечитанную.
Глава 1.2. Objects and Concurrency
Чётко перечислены и описаны накладные расходы параллельности: Sharing, Scheduling, Communication.
Оказывается, на Java можно создавать lighter-weight frameworks, если перечисленные свойства Thread становятся проблемой для производительности. Интересно, как.
Первым параллельным языком была Simula.
Я неправильно перевожу "конкурентный" как "параллельный". Параллельный - это когда каждая задача выполняется на своём процессоре и процессы общаются только через сообщения. А конкурентный - это со всеми прелестями именно что конкурентного доступа к переменным, race conditions.
Глава 1.3 Design Forces
Новое:
Выражение конкурентной системы в противостоянии Инь и Ян... то есть:
Safety. Nothing bad ever happens to an object.
Liveness. Something eventually happens within an activity.
Другие имена великих начал -
Reusability. The utility of objects and classes across multiple contexts.
Performance. The extent to which activities execute soon and quickly.
Далее конкурентное программирование рассматривается с точки зрения Дао... то есть этих аспектов.
Наконец точно узнал, чем чреваты пресловутые race conditions.
Это так-таки всего-навсего два конфликта:
Как часть возможной модели, вводятся варианты атрибутов:
- непосредственное значение;
- кэшированное значение;
- булевское значение, управляющее логикой кода;
- состояние процесса выполнения;
- история предыдущих состояний;
- версия (таймстамп);
- ссылки на объекты, с которым объект общается, но которыми не владеет;
(кстати, кто предложит атрибут, не укладывающийся в эту модель?)
Классификация ошибок/проблем конкурентности.
- locking & waiting, input (проблема ли это?), CPU contention (никогда-не-получение тредом ЦПУ), перманентная thread failure, deadlocks, и nested monitor lockouts (чем они различаются?), missed signals, livelock (вариант дедлока, когда попытки залочить не ждут, а крутятся в цикле), starvation (чем не CPU contention?), resource exhaustion, distributed failure.
Очень хорошая подборка критериев производительности, которая может в какой-то степени ответить на вопрос Сергея о том, как вообще мерить производительность распределённой (т.е. тоже конкурентной/параллельной) системы (за расшифровкой см. книгу ;):
- Throughput;
- Latency;
- Capacity;
- (Resource) Efficiancy;
- Scalability;
- Degradation;
И причины её падения:
- Locks;
- Monitors;
- Threads;
- Context-switching;
- Scheduling;
- Locality;
- Algorithmics.
Подняты проблемы повторного использования. Повторное использование компоненты, даже тред-безопасной самой по себе, может приводить к проблемам с тредами.
Вот ведь как.
Особое внимание в свете конкурентности уделяется инкапсуляции (Restricted external communication) и консистентности (Deterministic internal structure).
В секции "Документирование" подчёркивается важность инвариантов.
1.4 Before/After Patterns
Пошло непонятное.
"The fields of any object should preserve all invariants whenever the object is not engaged in a public method"
Но откуда это следует - именно public? Что, в private нельзя записать последовательно в два поля, не лоча их, а в public можно? Ссылка на секцию 1.3.1, "Safety" вопроса не прояснила. Или наоборот, именно публичные методы так-таки обязаны сохранять инварианты только в начале и конце, а остальные не обязаны? (Это более вероятно)
В чём важность именно before/after проверок инвариантов - такая, что ей нужно было посвятить целую главу?
Tags: