juan_gandhi | milewski says

"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."

Flat | Top-Level Comments Only

From:

yigal_s

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

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

Вообще, я б хотел увидеть того гения, который напишет два объекта, каждый из которых будет data-race-free, а их композиция - не будет. )))

Edited Date: 2014-06-10 12:19 am (UTC)

From:

nine_k

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

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

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

From:

badula.livejournal.com

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

Edited Date: 2014-06-10 12:42 am (UTC)

From:

yigal_s

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

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

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

Edited Date: 2014-06-10 12:45 am (UTC)

From:

badula.livejournal.com

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

From:

yigal_s

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

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

From:

nine_k

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

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

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

From:

badula.livejournal.com

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

С оборачиванием есть ещё более стрёмная проблема - на основании как угодно атоммарно прочитанного значения обёрнутого поля нельзя сделать никаких модификаций чего бы то ни было, потому что прочитанное прямо в момент прочтения становится неверным. А обернуть все потенциальные мутации весьма сложно.

Edited Date: 2014-06-10 12:46 am (UTC)

From:

yigal_s

перенос денег никакого отношения к data-race не имеет.

"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."

Это определение касается одной ячейки памяти, и только.

Если б Милевский просто написал "data race" и начал говорить после этого про банковские операции, т.е. о "race conditions" общего типа - это бы означало, что он то ли не знает смысла этого термина, то ли ошибся. Сие простительно. Но, увы, он не только привел термин, но и дал его определение. Тут уж приходится предполагать, что он чего-то крепко не понимает.

Edited Date: 2014-06-10 12:56 am (UTC)