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

[sassa-nf.livejournal.com]

he has a point, but we define races differently (people should be expelled from the Guild for saying "at the same time").

[vit-r.livejournal.com]

Какой ужас. Оказывается Шыллор с Мыллором нифига не знали про эти сложнейшие траблы и без проблем придумали, как генерить параллельный софт прямо из объектно-ориентированных моделей.

Не, честное слово, этот поиск Надёжного Средства для Всех Идиотов и привёл индустрию софтописания туда, где она сейчас находится.

[yigal_s]

* без проблем придумали, как генерить параллельный софт прямо из объектно-ориентированных моделей.

Не могли бы Вы просветить и поделиться ссылкой на упоминаемые вами результаты? Очень бы хотелось изучить. Заранее спасибо.

[vit-r.livejournal.com]

Результаты чего? Софт генерённый - он во встроенных системах в основном, и не знаю, кто им делиться будет. Просто информацию можно найти сейчас по ключевым словам Executable UML и частично по словам Action Language UML

[fatoff.livejournal.com]

Oh, I watched his videos "C++ 11 async programming" like 2 years ago.
Also watched the one where he teaches Haskel to ones who know C++.

The guy who published C++ 11 async feature online course does know there drawbacks. But with just C programming the same tasks as he showed in his course, such as Map Reduce it is many degrees of magnitude more difficult.

Works like a charm and who cares, let the object talk to another object via some messages. If the messaging mechanism is Ok and shared resources are safe, why not do multithreading with C++ 11 objects? Doing that right now...

[badula.livejournal.com]

суть сообщения не в том что c++ ужасен, хотя люди с религиозной одержимостью проповедуют и это, наряду с любой другой __йнёй, а в том что races вызываются переменчивостью "объектов". что, собственно, очевидно и о чём можно в двадцать первом веке уже и не поминать. языки типа эрланга сделанные с самого начала для параллельной работы никакой mutability не допускают, прямого управления параллельностью в них нет, все перемены локализованы в нитях и производятся метанием сообщений.
всё подлежащее, понятное дело, реализовано на обычных языках, но к строительству енвайронментов для своих языков immutable люди относятся примерно как водители к дорожным рабочим — х_й какой водитель мерседеса бенца сумеет проложить хоть метр дороги, что ни разу не мешает ему ехать мимо с задранным носом.

если смотреть на вселенную через телескоп fp-людей, oo-код постоянно решает невыполнимую задачу мониторинга переменчивого и следовательно непредсказуемого состояния своих "объектов". вызовы методов - рассадник "side effect'ов" — большое "no-no" с точки зрения fp…

[fatoff.livejournal.com]

Что интересно, тот же самый Милюски читает вполне внятные лекции про C++ 11 и как на нём реализовать разные типы многопоточных задач.

[anton-solovyev.livejournal.com]

nice

[blackyblack.livejournal.com]

Где это они "hide sharing"? Наоборот, они должны инкапсулировать данные. Организация многопоточного доступа соответственно на совести программиста. Да, было бы удобно иметь встроенную в язык поддержку аннотаций, мол класс thread-safe или нет. Но и так жить можно.

[archaicos.livejournal.com]

So, where's the news?

[fatoff.livejournal.com]

No news. The guy forgot to mention an adequate messaging mechanism which makes everything working like a charm.

[sab123.livejournal.com]

Captain Obvious?

[ivan-gandhi.livejournal.com]

Да кому как, похоже.

[yigal_s]

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

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

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

[nine_k]

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

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

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

[badula.livejournal.com]

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

[yigal_s]

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

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

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

[badula.livejournal.com]

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

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

[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" общего типа - это бы означало, что он то ли не знает смысла этого термина, то ли ошибся. Сие простительно. Но, увы, он не только привел термин, но и дал его определение. Тут уж приходится предполагать, что он чего-то крепко не понимает.

[yigal_s]

*С оборачиванием есть ещё более стрёмная проблема

Я предложил решение data races, а не всех race conditions ;-)

[zyxman.livejournal.com]

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

[zyxman.livejournal.com]

Ну что еще можно ожидать от ассемблера высокого уровня? :P

- Естественно, если объекты используют типы данных, дозволяющие фривольности употребления себя и при этом не имеющие защиты, так будут проблемы.
А фактически, всего навсего нужно эти объекты пересобрать с concurency-safe типом данных.
Кстати, это можно сделать и при позднем связывании, хотя конечно это уже будет не нейтивный код, а язык с++ внутри виртмашины.

Да, я буквально имею в виду, что в pure ФП языках всего навсего отказались от классического аппаратного типа данных, а вместо него использовали тип данных высокого уровня, ну и соответственно, уже далее надстройки - вместо прямого шаринга небезопасного типа, в одних языках сообщения, в других транзакционная память (каждый из двух вариантов имеет свои преимущества и недостатки, лично мне, как любителю отказоустойчивых систем, больше нравятся сообщения).

[zyxman.livejournal.com]

PS ИМХО, проблема уровня спора "чья культура древнее"
PPS Проблема, что после записи одним, чтение другого уже должно делать дополнительные телодвижения по синхронизации, от кривости архитектуры объектов.

[blackyblack.livejournal.com]

Проблема в том, что концепция вызовов методов объектов вместо передачи сообщений подрывает весь ОО подход. Сделали бы в C++ обмен сообщениями по дефолту, всем стало бы легче.

[http://users.livejournal.com/_xacid_/]

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

и ни в коем случае не наоборот (как это делают сейчас, иногда).