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

[yigal_s]

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

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

[vit-r.livejournal.com]

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

[yigal_s]

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

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

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

[vit-r.livejournal.com]

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

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

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

[yigal_s]

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

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

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

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

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

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

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

[vit-r.livejournal.com]

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

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

[yigal_s]

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

[vit-r.livejournal.com]

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