Observations

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

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

From:

yigal_s

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

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

From:

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

From:

yigal_s

* Результаты чего?

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

О какой именно работе Shlaer-Mellor идет речь? И да, эта самая генерация параллельного софта, она что, решает проблемы построения thread-safe системы?

From:

Когда-то было время, люди, даже не в этой области ИТ работающие, про Шыллор с Мыллором вопросов не задавали...

Да, решает. Как можно иметь параллельный и не thread-safe?

Работ дофига. В том числе в Мыллор внёс свою лепту в исправление убожества UML.

From:

yigal_s

* Да, решает. Как можно иметь параллельный и не thread-safe?

Разумеется. Я сейчас объясню, что имею в виду:

Характерные проблемы/ошибки при разработке многопоточного софта - т.н. race conditions и дедлоки. Собственно, мне и было интересно, решает ли их автоматически методология Shlaer-Mellor и если решает, то как именно и в каких конкретно статьях это описано.

Т.е. вот это самое решение race conditions и дедлоков, оно должно быть обеспечено одной из двух альтернатив:

а) в самой объектно-ориентированной модели, трудами дизайнеров и аналитиков

б) объектно-ориентированная модель о такой ерунде не заботится, зато генератор авторства Shlaer-Mellor, что генерит софт из объектно-ориентированной мдели умеет все эти проблемы разрешать (не создавать) и на выходе мы получаем прекрасный безопасный мультитредный код.

Мне кажется, то, что вы описываете - это альтернатива (б) и сие чрезвычайно интересно. Если бы вы могли дать ссылку на конкретную работу Shlaer-Mellor, описывающую технические подробности данного решения, свободного от дедлоков и race conditions, это было бы чрезвычайно интересно.

Edited Date: 2014-06-11 03:24 am (UTC)

From:

Дедлоки бывают разные. Когда идёт борьба за внешние ресурсы, не поможет и функциональное программирование, надо прикручивать что-то ещё.

Когда в софте есть слова embedded и mission critical, все элементарные проблемы решаются из коробки, но отвечать на вопрос также интересно как и на что-то вроде "В какой статье Буч доказал, что объекты инкапсулируют данные?"

From:

yigal_s

я остаюсь в результате этого разговора в полном недоумении, и это единственное, что мне остается сказать.

From:

Это не мои проблемы.

From:

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

From:

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

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

Edited Date: 2014-06-09 09:08 pm (UTC)

From:

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

From:

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

From:

Да и C++ там вовсе не для одной утилитарной задачи разделения вычислений по ядрам. Ведь никто не ответит, как Scala захостит RDP ActiveX control, что есть требование.

From:

В этом месте важно отделить язык от платформы на которой он стоит в разных конкретных случаях. На C++ захостить контрол не менее невозможно если этот C++ компиляется для OSX'а. А вот проще ли на Cкале вычленить из протокола отдельные сообщения, превратить их в графические пикселы, звуковые семплы и байты редиректнутого USB — я понятия не имею. Сделать можно, понятное дело, но придётся ли написать меньше кода по сравнению с Джавой или C++ — хрен его знает. Может и нет. Будет ли меньше дефектов — тоже вопрос. Наверное будет меньше. Насколько шустро оно будет работать — третья ось для сравнения.

Edited Date: 2014-06-09 11:20 pm (UTC)

From:

Пытаемся отделить. А под Mac OS (это наш тоже таргет) там в обязательном порядке, очень даже известно, есть много чего одному МакОСу понятного. Куда ни кинь - всюду клин, и только одна возможность оставаться тупым ренегатом C++. :-p

From:

количество дефектов можно урезать очень драматично.

К сожалению, в наше время это только проповеди и я не видел ни одного доказательства в реальных цифрах на реальных проектах.

Переход на новую парадигму банально переносит источник проблем в другие области.

From:

Так подобные доказательства никому не нужны. Для доказательства нужно один и тот же проект одними и теми же силами сделать два раза и в промежутке забыть про весь опыт предыдущей стройки. Слишком дорого ради какого-то доказательства. За примером успешного дико сложного проекта на функциональном языке можно сходить в эриксоновские свичи. А за примером неуспешного идентичного но на C++ - в алкателовские.
"Я не видел значит его нет" это какой-то уж черезчур эмпирический подход. Главврач этого журнала вон какое-то дело жизни производит вообще на Скале и не жалуется на дефектность товара.

From:

Наука от религии в том и заключается, что факты доказывают не гаданием, а экспериментами. В прошлом веке люди на такое дело деньги тратили. Причём, в виде времени квалифицированных специалистов. Сейчас "доказывают" на десятке студентов, потом начинают проповедовать на всех углах.

Разница между фирмами в производстве софта - двадцатикратная. (Если считать, что ДеМарко эксперименты ставил честно.) Так что культура забивает все мелочи, включая технологии.

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

From:

Дефекты есть, да что жаловаться; это ж реальность. Принимать как есть.

From:

thedeemon.livejournal.com

Он же теперь профессиональный пропагандист хаскеля, работает в FP Complete.

From:

helvegr.livejournal.com

Уже не работает.

From:

anton-solovyev.livejournal.com

nice

From:

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

From:

archaicos.livejournal.com

So, where's the news?

From:

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

From:

sab123.livejournal.com

Captain Obvious?

From:

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

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:

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

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:

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

From:

yigal_s

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

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

From:

nine_k

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

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

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

From:

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

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

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)

From:

yigal_s

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

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

From:

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

From:

Базирующееся на темпоральной логике, базирующейся на топосной логике - там все научно верно.

From:

stanklimoff.livejournal.com

ой, а расскажи мне про этот момент? ты завтра будешь в симантеке?

From:

Буду.

From:

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

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

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

From:

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

From:

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

From:

thedeemon.livejournal.com

Было бы приколько рассмотреть пример с переводом денег между счетами в вариантах message passing (посылаем деньги в сообщении, они теряются) и с persistent data structure (посыл денег создает новый счет, но где-то мы продолжаем смотреть на старый). :)

From:

result = account->call(add_money, 100);
if(!result) alert();

call - синхронная отправка сообщения.

From:

thedeemon.livejournal.com

И чем это отличается от "вызовов методов объектов вместо передачи сообщений"?

From:

В принципе ничем. Ну если не считать, что можно прозрачно подменять вызов для распределенного применения.
Но есть ведь и асинхронные сообщения.

From:

stanklimoff.livejournal.com

ну, "прозрачно заменить" это вы далеко хватили :)

From:

Alan Kay once said, "I invented the term object-oriented and I can tell you I did not have C++ in mind." What Alan Kay described was message passing, isolation between objects, and polymorphism. That describes Erlang better it describes Java.

From:

Обмен сообщений требует фактически высокоуровневых ячеек памяти, то есть вся совместимость с старым Си ломается.

From: