Здравствуйте, Basil2, Вы писали:
B>В Rust еще не знаю, а в Go это типа суперфича языка. Ты хоть тысячи потоков создаешь, а Go сам раскладывает их в несколько потоков операционки.
В Rust зеленых потоков не осилили, изначально такая фича была. Сейчас там 1:1 через threads. Зато каналы осилили, что уже большой шаг вперед я считаю.
Здравствуйте, Basil2, Вы писали:
B>При всей моей любви к С++, многопоточность там сделали очень угребищно. Std::thread c его terminate и std::async, которой вовсе не асинк даже в случае с std::async(std::async::async), это просто что-то с чем-то. Как-то не хочется в эту трясину лезть.
Да ладно, все не так плохо, не хуже чем в Rust, по большому счету, разве что нет канала, но при том, что канал — это потоко-безопасная очередь, то соорудить его подобие не сложно, ведь r/w синхронизация еще с C++11 имеется. Понятно, что не Go по возможностям, но тоже хорошо.
Кроме того, комбинации promise/future для многих задач вполне достаточно, лично меня печалит то, что о необходимости when_any/when_all задумались только в рамках concurrency TS.
Здравствуйте, Basil2, Вы писали:
B>Конечно. ++ возвращает ссылку, а она невалидна в многопоточной среде. А если возвращать значение, то нарушится стандартная сигнатура, что тоже нехорошо.
А много существует сценариев, когда от атомарной переменной в таком контексте требуется именно ссылка, а не значение?
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
Здравствуйте, kaa.python, Вы писали:
B>>При всей моей любви к С++, многопоточность там сделали очень угребищно. Std::thread c его terminate и std::async, которой вовсе не асинк даже в случае с std::async(std::async::async), это просто что-то с чем-то. Как-то не хочется в эту трясину лезть.
KP>Да ладно, все не так плохо, не хуже чем в Rust, по большому счету,
Я многопоточность Rust только изучаю, но пока там не видится тех жоп, которые аж by design есть в С++ примитивах. Причем жопы так и были задуманы, я полдня не мог понять, почему два async() не выполняются асинхронно.
KP>разве что нет канала, но при том, что канал — это потоко-безопасная очередь, то соорудить его подобие не сложно, ведь r/w синхронизация еще с C++11 имеется.
Несложно, однако в Rust каналы — это дефолтный способ обеспечения синхронности.
KP>Понятно, что не Go по возможностям, но тоже хорошо.
А в Go есть что-то кроме каналов и встроенного тред-пула?
Проект Ребенок8020 — пошаговый гайд как сделать, вырастить и воспитать ребенка.
Здравствуйте, Ops, Вы писали:
B>>Конечно. ++ возвращает ссылку, а она невалидна в многопоточной среде. А если возвращать значение, то нарушится стандартная сигнатура, что тоже нехорошо.
Ops>А много существует сценариев, когда от атомарной переменной в таком контексте требуется именно ссылка, а не значение?
Их может и вообще не быть. Но стандартная сигнатура оператора ++ определена как
T& operator++();
а нарушать их считается дурным тоном.
Проект Ребенок8020 — пошаговый гайд как сделать, вырастить и воспитать ребенка.
Здравствуйте, Basil2, Вы писали:
B>Их может и вообще не быть. Но стандартная сигнатура оператора ++ определена как B>
B>T& operator++();
B>
B>а нарушать их считается дурным тоном.
Это все предрассудки, тем более что в стандартной библиотеке вполне себе нарушают, я рядом привел ссылку. Одно дело, когда это может создать реальные трудности, другое — религиозные причины.
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
Здравствуйте, Ops, Вы писали:
B>>Их может и вообще не быть. Но стандартная сигнатура оператора ++ определена как B>>
B>>T& operator++();
B>>
B>>а нарушать их считается дурным тоном.
Ops>Это все предрассудки, тем более что в стандартной библиотеке вполне себе нарушают, я рядом привел ссылку.
Да, в атомиках-то учли эту проблему и сигнатуру поменяли. Дык изначальный-то пост именно про это и был — что есть нюансы, причем весьма неочевидные и настолько же серьезные.
Проект Ребенок8020 — пошаговый гайд как сделать, вырастить и воспитать ребенка.
Здравствуйте, Basil2, Вы писали:
B>Да, в атомиках-то учли эту проблему и сигнатуру поменяли. Дык изначальный-то пост именно про это и был — что есть нюансы, причем весьма неочевидные и настолько же серьезные.
Так я по конкретному вопросу из начального поста
Например, я как-то сделал класс для многопоточного счетчика через операцию ++. А тимлид сказал что так нельзя, ибо стандартная сигнатура операции ++ не позволяет корректно вернуть результат в многопоточной среде, и надо использовать функцию-член типа inc().
В чем отличие твоего класса от атомика (вероятно, урезанного), что нельзя сделать этот момент так же, как там? Аргумент "не та сигнатура" кажется мне исключительно религиозным, по крайней мере пока нет реальных, не синтетических, примеров, когда требуется именно ссылочный тип в таком контексте.
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
Здравствуйте, Basil2, Вы писали:
KP>>Зато каналы осилили, что уже большой шаг вперед я считаю. B>Да, я на каналах планирую делать.
Тут надо быть довольно осторожным. Судя по начальному вопросу четкого понимания что делать нет, но Rust не дает никаких бонусов кроме каналов относительно C++, при этом по сложности вобщем-то сопоставим. Может все-так Go?
Здравствуйте, Basil2, Вы писали:
B>>>При всей моей любви к С++, многопоточность там сделали очень угребищно. Std::thread c его terminate и std::async, которой вовсе не асинк даже в случае с std::async(std::async::async), это просто что-то с чем-то. Как-то не хочется в эту трясину лезть.
Ничего не понял... std::async(std::async::async) гарантирует выполнение в отдельном потоке. Разве нет?
Asynchronous: Launches a new thread to call fn (as if a thread object is constructed with fn and args as arguments, and accessing the shared state of the returned future joins it).
Тут скорее не угребищно сделали, а мало сделали, но очень грамотно, что несколько про другое.
B>Я многопоточность Rust только изучаю, но пока там не видится тех жоп, которые аж by design есть в С++ примитивах. Причем жопы так и были задуманы, я полдня не мог понять, почему два async() не выполняются асинхронно.
Потому что они могут выполняться асинхронно, но не обязаны, в чем жопа то?
B>Несложно, однако в Rust каналы — это дефолтный способ обеспечения синхронности.
Который а) не бесплатен, б) не отменяет того, что все потоки нативные и с ними надо уметь работать. Так же как и в C++.
B>А в Go есть что-то кроме каналов и встроенного тред-пула?
О, тут много что есть. Во-первый, тут есть чудесная система модулей запрещающая циклические зависимости, во-вторых, есть отличные интерфейсы, ну и в-третьих, есть великолепная читабельность кода, ни с чем не сравнимая.
Я не часто операторы реализую, но когда недавно писал итератор, то обратил внимание на тот факт, что ссылка возвращается только в одном случае, во втором по начению.
Здравствуйте, kaa.python, Вы писали:
KP>Кроме того, комбинации promise/future для многих задач вполне достаточно,
promise/future из стандартной библиотеки на данный момент ни на что кроме hello world не годен: Нет возможности добаваить continuation. Т.е. он имеет изначально сломанный интерфейс. И без concurrency TS, без executors его не исправить. Но concurrency TS — это 2023 в лучшем случае.
Большой оверхед. На последнем CppCon было несколько докладов, где предлагались свои варианты future которые используют обьекты синхронизации только когда это действительно нужно.
KP>лично меня печалит то, что о необходимости when_any/when_all задумались только в рамках concurrency TS.
Даже в бусте when_any/when_all нормально сделать не смогли. Создают вспомогательные потоки и делают ожидание в них. И как выполнить например 1000 ожиданий?
"For every complex problem, there is a solution that is simple, neat,
and wrong."
мухи, котлеты и еще вишенка на блюдечке
> многопоточность, сетевой сервер MMO, использовал C++ но без привязки к языку ....
я вот реально не понимаю людей которые с возможно большим опытом в разработке не могут сформулировать вопрос
многопоточность и примитивы синхронизации начинаются с изучения устройства и работы CPU и ОС
это как раз то что без привязки к языку изучается
дальше в каждом языке по разному. Erlang, Go, Java, C# и тот же C++
надо изучать отдельно
в них все по разному
дальше идет сетевая архитектура и применительно к языкам описанных выше от нее к ним большой разрыв
т.е. опять нужно изучать совершенно другое
если у вас нет опыта сетевой разработки, то даже просто что то почитав, вы в этот поезд еще долго не запрыгните
и определитесь наконец то с самым главным на мой взгляд, языком реализации
Здравствуйте, kaa.python, Вы писали:
KP>Я бы сказал что паттерна, основных, на данный момент два три: CSP, акторы и прямой путь в ад — шареная память.
Таки есть еще task-based подход (TBB TaskGraph, cpp-taskflow, отчасти HPX). Хотя можно еще и реактивное программирование помянуть. Но в контексте задачи топик-стартера разве что CSP и акторы имеет смысл рассматривать.
Что напечатает?
B>>А в Go есть что-то кроме каналов и встроенного тред-пула? KP>О, тут много что есть. Во-первый, тут есть чудесная система модулей запрещающая циклические зависимости, во-вторых, есть отличные интерфейсы, ну и в-третьих, есть великолепная читабельность кода, ни с чем не сравнимая.
Я в смысле многопоточности, а не языка вообще.
if err != nil {
return err
}
Проект Ребенок8020 — пошаговый гайд как сделать, вырастить и воспитать ребенка.
Здравствуйте, kaa.python, Вы писали:
KP>Тут надо быть довольно осторожным. Судя по начальному вопросу четкого понимания что делать нет, но Rust не дает никаких бонусов кроме каналов относительно C++, при этом по сложности вобщем-то сопоставим. Может все-так Go?
А смысл? Rust превосходит Go практически во всем: скорость, надежность, мощность, выразительность, обработка ошибок. На Go проще запиливать веб-сервисы, за счет чего его доля быстро растет, т.к. он заменяет одновременно Python, Node.JS, C#, Perl и PHP. Но мне больше нравится системная тема.
Проект Ребенок8020 — пошаговый гайд как сделать, вырастить и воспитать ребенка.
1234 напечатает. Но это не баг, это фича... как бы.
B>
B>if err != nil {
B> return err
B>}
B>
B>)
И? Явная обработка ошибки. Ты просто из C++ мира смотришь на что-то новое и кажется странно, но это не так, это просто новое и не на ровном месте возникшее.
