milewski says

[juan_gandhi]

"Unfortunately, objects don’t compose in the presence of concurrency. They hide the wrong kind of things. They hide sharing and mutation. Let me quote the definition of data race: Two or more threads accessing the same piece of memory at the same time, at least one of them writing. In other words: Sharing + Mutation = Data Race. Nothing in the object’s interface informs you about the possibility of sharing and mutation inside the object’s implementation. Each object in isolation may be data-race-free but their composition may inadvertently introduce data races. And you won’t know about it unless you study the details of their implementation down to every single memory access."

Comments

[nine_k]

Это ваше высказывание меня удивляет.

Положим, вам надо в объекте поменять два поля согласованно. Что вы будете оборачивать?
А если два поля меняются независимыми методами объекта?
А если между вызовом первого их этих методов и второго надо вставить некоторое не очень короткое вычисление?

Не то чтобы всё это невозможно было решить — но "элементарным" я бы такое решение не назвал. Решение "в лоб" в третьем случае чревато потерей ещё и перформанса.

[badula.livejournal.com]

Два поля можно завернуть в один метод с двумя параметрами. Хрен с ним что не изящно, синхронизация остаётся внутри метода. Вставить вычисление можно добавив параметры которые его произведут. Лямбду какую-нибудь. Когда объектов становится больше одного начинается вынос синхронизации из объектов. Что впрочем неизбежно, просто Хаскел это скрывает от, не к столу будет сказано, программиста.

[yigal_s]

существует понятие "data race", Милевски дал его вполне внятное определение, вполне соответствующее общепринятому, и, судя по прочему его тексту именно это имеет в виду. Это понятие вообще никоим образом не связано с тем, чтобы "поменять два поля согласовано", ибо говорит о доступе к единичным ячейкам памяти.

Та проблема, о которой говорите Вы - это "race condition" общего типа - ровно то, что заботит обычных прикладны программистов, и действительно, являющееся при композиции "thread-safe" объектов, написанных, скажем, с помощью блокировок, крайне серьезной проблемой.

"race condition" и "data race" - разные вещи.

[badula.livejournal.com]

В тексте он говорит как раз про race conditions общего вида. Про один очень узекий частный случай иногда говорят как про "data race", но этот разговор может быть интересен дизайнерам железа которым нужно как-то решить кто что запишет и кто что прочитает.

[yigal_s]

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

"data race" - это вполне уже сфера интереса программистов, вот скажем спецификации модели памяти С++ этот термин должны использовать, и я предполагаю, что стандарт С++ пишется для программистов.

[nine_k]

О, так понятно.

Действительно, data race при доступе к тому, что логически описано как атомарное, триваильно решается устройством синхронизации вокруг точки доступа.

А вопрос мой относился именно к композиции (где race conitions, deadlocks и прочие радости), про которую исходный пост, но не ваш коммент.