Грубо говоря, сообщения обрабатываются в одном главном цикле в огромном switch/case - так что один case ну никак не может ждать другого case.
А как у нас с многопоточностью этого огромного switch/case ? Вроде с этого требования начинали.
Есть фундаментальные ограничения на взаимные блокировки в параллельных средах исполнения. Сколько лет уже SQL базы пилят, но нет решения, как избежать дедлоков. Серебряной пули нет, к сожалению (((
Послушайте, ну перестаньте на секундочку держать собеседника за идиота,
Вас? Да упаси хосподи! Уж точно кем- кем, а идиотом Вас считать ну совсем нет никаких оснований! Манипулятором - возможно, но не идиотом.
Отправил и забыл.
Запросил значение и результат не интересен? А тут вдруг тот у кого запросили значение пришёл обратно (через длинную цепочку, с условиями, но так сложились звёзды...), и для ответа требуется запрошенное значение... Грусть-тоска. Так, конечно, в мире где каждая транзакция не менее 50М (Зибвамбвийских?) не бывает, но жизнь немного сложнее hello world, и по этому ответ на вопрос "обеспечивает ли акторная модель отсутствие дедлоков" однозначен - нет. Значит ли, что акторная модель не применима? Конечно не значит. Более того, она является пожалуй наилучшей (из универсальных) при реализации взаимодействия между процессами, идущими на разных ядрах, но как указывал уважаемый @rsashka, замечание которого про то, что сколько гринтредов ни крутятся в рамках одного треда ОС - подход к примитивам взаимной синхронизации совершенно иной, при этом в большинстве случаев примитивы синхронизации вообще не требуются, к сожалению, остался без должного внимания, хотя это лучший вариант с точки зрения обеспечения производительности.
Понятно, что по существу у Вас аргументов не имеется. (((
Ну, когда люди начинают в дискуссии юродствовать, всем всё становится понятно.
Парадигма или даёт гарантии или нет. Нельзя быть немного беременной. Напомню, что изначально разговор шёл об ужасных дедлоках в ООП при применении мьютексов.
P.S. Но всё равно большое спасибо за Ваши статьи, они заставляют вернуться к обдумыванию важных вопросов и вне зависимости от выводов, которые мы сделаем, периодически размышлять на эти темы крайне полезно.
Посылать синхронное сообщение самому себе из обработчика другого сообщения — это настолько редкий и безумный случай, что люди отучаются так делать на втором часу знакомства.
Связи могут быть длинные A ждёт B, B - C, C - ...., ... - Z, Z-A. И усё.
В акторной модели все сообщения асинхронны, поэтому создать дедлок можно только дожидаясь сообщения от самого себя изнутри обработчика предыдущего сообщения
Так можно и про мьютексы сказать - "словить дедлок можно только ожидая уже захваченный мьютекс". Однако такое определение счастья не приносит.
что банально отлавливается простейшим тулингом.
Подождите, мы вроде про парадигмы говорим, а не про некоторый тулинг, который чёто там может отловить (или не отловить).
Кроме того, зависимости бывают сложные, например, наличие зависимости по некоторому условию, и тулингу будет мешать теорема об останове исключить ложно положительные срабатывания.
Однако утверждать, что вся объектная модель обречена в многопоточном мире, неверно.
Реальный параллелизм всегда сложен и, по своей природе, потенциальные дедлоки ему всегда сопутствуют при появлении взаимного влияния частей системы. Даже в пропагандируемой автором акторной модели дедлоки возможны: A ждёт ответа от B а B - от A.
Подход с иммутабельными объектами безусловно решает ряд проблем, таких как внутренняя консистентность объекта, но тянет за собой местами излишние копирование на каждый чих и при этом не является единственно возможным подходом. Это спор скорее религиозный. (Во многих реальных случаях изменение объекта на spinlock для сохранения консистентности не оставит конкурентам ни малейшего шанса в вопросах производительности)
Дело в описанном в посте - ООП не справляется с этой сложностью, вот что с ним не так в 2025. Поэтому смысл менять шило на мыло.
Ну так приведите примеры соизмеримых по сложности систем без ООП
Здесь так и напрашивается "надо было еще ассемблер взять, еще веселее бы пошло"!
И что же подходит для фронта компилятора по Вашему мнению? Ксло, на C у меня тоже получилось, только несколько странно - пришлось реализовывать руками то, что и так есть в C++. Будучи переписано на плюсы стало логичнее и структурированее именно за счёт ООП.
Не надо путать ABI платформы, который определяет вещи типа в каких регистрах кто передает, и бинарную совместимость скомпилированннного кода. Очень разные вещи.
Вы удивитесь, но совершенно спокойно линкуются объектники собранные clang и gcc (упреждая вопрос - да, без всяких extern c).
Вроде сложные, а как посмотришь на обилие и частоту дыр
Дело, конечно, в ООП )))
Опять забывание исторических причин - начинался-то он с одного единственного, а потом накопленная кодовая база, которую уже нельзя просто так взять и переписать. Поэтому они и перешли с Си на С++ в виду отсуствия выбора фактически.
Исторически LLVM вообще непойми чем был )) и вроде с C++ и начинался.
На функциональном языке? Скриптовом?
На C. Скажу, что на плюсах дело пошло много веселее, именно из-за наследования и полиморфизма.
У плюсов для системного программирования и особенно ядра множество других проблем - вот начиная прям с отсутствия единого стандарта на ABI (ага, мэнглинг).
Проблемы менглинга в рамках одного компилятора нет от слова вообще. (На всякий, напомню, что Linux долгое время собирался исключительно GCC из-за его нестандартных расширений и конкретного поведения при некоторых UB), да и что GCC, что LLVM используют один и тот-же Itanium ABI, так что различия на сегодня если и есть, то только чисто косметические. (Фантазии MSVC рассматривать не стоит). Да и практика применения C++ в ядрах показывает несущественность этой проблемы.
Rust, при всех его недостатках и проблемах в этой сфере, и то перспективнее выглядит, чем плюсы.
Все перечисленные примеры - очень сильно ограничены в выборе языков.
Хотите другие - пожалуйста: V8, тот-же Chrome в качестве сложных подойдут?
Компилятор должен бутстрапиться сам собой, в ядрах ОС тоже нужен низкоуровневой язык (причем из набора многолетней давности, а с тех пор совместимость же).
LLVM имеет фронты для большого количества языков. Может бутстрапиться с любого.
И о фронтах - имхо, фронт для компилятора писать без ООП - тоска смертная, я пытался.
Кстати, слухи об ООП в ядрах сильно преувеличены - оно там не "есть", а бывает в форме не всякой, а нужной для конкретного места, в довольно ограниченном количестве мест.
Весь IOKit в макосике, WDK в виндах достаточно "бывает" ? То, что плюсы не пролезли в Linux на замену эмуляции объектов на сях - личная придурь Великого Фина - его единственный тезис про exception в конструкторе вызывает некоторое недоумение - индустрия знает множество примеров применения подмножеств C++ для увеличения производительности (в том числе и отказ от exception и RTTI, как это сделано в LLVM и в том, что связано с ядрами ОС)
Самые крупные математические библиотеки написаны на фортране
Мы вроде про сложность говорили.. Хотя вот tensorflow на С++.
Самые крупные банковские приложения написаны на коболе.
Хорошая попытка, но нет. Из top 10 инвесткомпаний США минимум 2 (это те, про которые лично мне достоверно известно) применяют C#. Может где-то кобол ещё и остался, но скорее это уже почти байка.
А есть практика, что по настоящему сложные системы написаны именно с применением ООП. LLVM например, GCC перешёл на C++, ядра виндов, макосика с применением C++, да и Linux хоть и на C, но с явным ООП
а Вы не замечали, что всё, что есть в индустрии - это 60-е и 70-е. ... Ничего нового собственно и нет
Горутины в совокупности с каналами - это очень хорошая абстракция
А вот это конкретно подпора для тех, кто боится что ктонить напишет while(true){}
Однозначно по многим параметрам. Есть, конечно, родовые травмы, но горутины и каналы на уровне языка - явный гуд.
На вкус и цвет все фломастеры разные.
Так и про мьютексы можно написать.
А как у нас с многопоточностью этого огромного switch/case ?
Вроде с этого требования начинали.
Есть фундаментальные ограничения на взаимные блокировки в параллельных средах исполнения. Сколько лет уже SQL базы пилят, но нет решения, как избежать дедлоков. Серебряной пули нет, к сожалению (((
"Есть многое на свете, друг Горацио, что и не снилось нашим мудрецам" (с)
Perl это уж очень сильно на любителя, имхо.
Возразить вообще нечего. (Ну может если только RTFM?)
Тем не менее, ядра пишутся, работают.
ErlangElexir конечно нужно всем посмотреть, но писать на нём лично я - пас. Go выглядит значительно привлекательнее по многим параметрам.Оно и без кластера ничего не гарантирует - NTP не даст соврать.
Оффтоп: ну уж Вам лучше этой темы не касаться ))
Вас? Да упаси хосподи! Уж точно кем- кем, а идиотом Вас считать ну совсем нет никаких оснований! Манипулятором - возможно, но не идиотом.
Запросил значение и результат не интересен? А тут вдруг тот у кого запросили значение пришёл обратно (через длинную цепочку, с условиями, но так сложились звёзды...), и для ответа требуется запрошенное значение... Грусть-тоска.
Так, конечно, в мире где каждая транзакция не менее 50М (Зибвамбвийских?) не бывает, но жизнь немного сложнее hello world, и по этому ответ на вопрос "обеспечивает ли акторная модель отсутствие дедлоков" однозначен - нет.
Значит ли, что акторная модель не применима? Конечно не значит.
Более того, она является пожалуй наилучшей (из универсальных) при реализации взаимодействия между процессами, идущими на разных ядрах, но как указывал уважаемый @rsashka, замечание которого про то, что сколько гринтредов ни крутятся в рамках одного треда ОС - подход к примитивам взаимной синхронизации совершенно иной, при этом в большинстве случаев примитивы синхронизации вообще не требуются, к сожалению, остался без должного внимания, хотя это лучший вариант с точки зрения обеспечения производительности.
Уже показывал дедлок в длинной связи:
Связи могут быть длинные A ждёт B, B - C, C - ...., ... - Z, Z-A. И усё.
Понятно, что по существу у Вас аргументов не имеется. (((
Парадигма или даёт гарантии или нет. Нельзя быть немного беременной.
Напомню, что изначально разговор шёл об ужасных дедлоках в ООП при применении мьютексов.
P.S. Но всё равно большое спасибо за Ваши статьи, они заставляют вернуться к обдумыванию важных вопросов и вне зависимости от выводов, которые мы сделаем, периодически размышлять на эти темы крайне полезно.
Связи могут быть длинные A ждёт B, B - C, C - ...., ... - Z, Z-A. И усё.
Понятно. Парадигма не обеспечивает. Ужос-Ужос!
Так можно и про мьютексы сказать - "словить дедлок можно только ожидая уже захваченный мьютекс". Однако такое определение счастья не приносит.
Подождите, мы вроде про парадигмы говорим, а не про некоторый тулинг, который чёто там может отловить (или не отловить).
Кроме того, зависимости бывают сложные, например, наличие зависимости по некоторому условию, и тулингу будет мешать теорема об останове исключить ложно положительные срабатывания.
Реальный параллелизм всегда сложен и, по своей природе, потенциальные дедлоки ему всегда сопутствуют при появлении взаимного влияния частей системы. Даже в пропагандируемой автором акторной модели дедлоки возможны: A ждёт ответа от B а B - от A.
Подход с иммутабельными объектами безусловно решает ряд проблем, таких как внутренняя консистентность объекта, но тянет за собой местами излишние копирование на каждый чих и при этом не является единственно возможным подходом. Это спор скорее религиозный. (Во многих реальных случаях изменение объекта на spinlock для сохранения консистентности не оставит конкурентам ни малейшего шанса в вопросах производительности)
Серебряной пули нет (с)
Ну так приведите примеры соизмеримых по сложности систем без ООП
И что же подходит для фронта компилятора по Вашему мнению?
Ксло, на C у меня тоже получилось, только несколько странно - пришлось реализовывать руками то, что и так есть в C++. Будучи переписано на плюсы стало логичнее и структурированее именно за счёт ООП.
Вы удивитесь, но совершенно спокойно линкуются объектники собранные clang и gcc (упреждая вопрос - да, без всяких extern c).
Пример прислать?
А что по вашему не "говно"?
Дело, конечно, в ООП )))
Исторически LLVM вообще непойми чем был )) и вроде с C++ и начинался.
На C. Скажу, что на плюсах дело пошло много веселее, именно из-за наследования и полиморфизма.
Проблемы менглинга в рамках одного компилятора нет от слова вообще. (На всякий, напомню, что Linux долгое время собирался исключительно GCC из-за его нестандартных расширений и конкретного поведения при некоторых UB), да и что GCC, что LLVM используют один и тот-же Itanium ABI, так что различия на сегодня если и есть, то только чисто косметические. (Фантазии MSVC рассматривать не стоит). Да и практика применения C++ в ядрах показывает несущественность этой проблемы.
Не думал, что Вы из этих
Хотите другие - пожалуйста: V8, тот-же Chrome в качестве сложных подойдут?
LLVM имеет фронты для большого количества языков. Может бутстрапиться с любого.
И о фронтах - имхо, фронт для компилятора писать без ООП - тоска смертная, я пытался.
Весь IOKit в макосике, WDK в виндах достаточно "бывает" ?
То, что плюсы не пролезли в Linux на замену эмуляции объектов на сях - личная придурь Великого Фина - его единственный тезис про exception в конструкторе вызывает некоторое недоумение - индустрия знает множество примеров применения подмножеств C++ для увеличения производительности (в том числе и отказ от exception и RTTI, как это сделано в LLVM и в том, что связано с ядрами ОС)
Ну, думаю, началось ...
Ну так перечитайте приведённую Вами же цитату.
Мы вроде про сложность говорили.. Хотя вот tensorflow на С++.
Хорошая попытка, но нет. Из top 10 инвесткомпаний США минимум 2 (это те, про которые лично мне достоверно известно) применяют C#. Может где-то кобол ещё и остался, но скорее это уже почти байка.
А есть практика, что по настоящему сложные системы написаны именно с применением ООП. LLVM например, GCC перешёл на C++, ядра виндов, макосика с применением C++, да и Linux хоть и на C, но с явным ООП
Быстрые - сильно от имплементации зависит. Уж сколько было убийц C/C++
А сложные - так ООП как раз и является методом управления сложностью