Зачем для организации динамически расширяющихся тредпулов вообще нужны мутексы? Чушь какая-то...
То наверное да, без мутексов в пуллах потом не обойтись.
Так "не обойтись" или "чушь какая-то"
Вы уж определитесь.
И речь шла не про очереди заявок для thread-pool-а.
Потому что в статье описан подход, который применим только к прикладной разработке
Ошибаетесь. Вам тут уже привели пример вашей же MDBX, в которой около 200 применений мутексов.
При чем тут принципы БД офтопик?
Подумайте.
С какой стати они вообще офтопик, если там все очень плотно на конкуретном доступе и реализовано?
Потому что там конкурентность для решения задач СУБД. Если создается, скажем, видеоредактор или прокси-сервер, то конкурентность и там потребуется, но вряд ли она будет такая же, как в случае с СУБД.
Что мутексы это круто и они очень хорошие и они всегда нужны?
В том и суть: заголовок претендует на что-то серьезное, а по факту получается такое себе.
Ну как можно всерьез отвечать собеседнику, который пишет ХЗ что про лучи и какие-то субстанции?
Вы, похоже, никогда не слышали выражения "посылать лучи поноса". Вот в данном случае эти самые лучи и были вам отправлены за то, что примеры кода вставлены картинками.
Если суть претензии для все все еще "ХЗ", то хотя бы обратите внимание на:
количество людей, поддержавших мой комментарий;
я не единственный, кто такую претензию озвучил.
Можно и дальше считать меня идиотом, а можно просто сделать выводы.
Тут был вопрос к корректности высказывания своих замечаний к статье.
Уверяю вас, что все замечания, которые вы не смогли адекватно воспринять, были сделаны в максимально корректной форме. Вы даже ни одного грубого слова не найдете.
Если потенциальному пользователю нужно дорабатывать ваш исходник напильником, то это сложно назвать "у меня готова полная реализация SharedState". Она либо не готова, либо не полная.
К тому, что ваш бенефис знаний о подходах из СУБД в комментариях к данной статье является офтопиком. Может быть он был бы уместен, если бы статья пыталась сравнивать разные подходы к решению проблем конкурентности в C++(*). Но нет, она не о конкурентности вообще, она о том, как уменьшить вероятность выстрелить в ногу если mutex-ы все-таки нужны.
Там куча "умных" слов про одно и то-же, когда вместо INSERT/UPDATE в базу данных всегда идет только INSERT, на каждое изменение. Тоже механизм обеспечения конкурентной согласованности.
Еще одна ваша проблема в том, что вы рассуждаете о сферических конях в вакууме. Нужно нехило так пораскинуть мозгами, чтобы понять, как идею MVCC использовать для решения той или иной задачи, не связанной с хранением данных в БД. А вы не даете никаких намеков на то, как эти самые "только INSERT на каждое изменение" применять в решении тех или иных задач. Только демонстрация собственной эрудиции, не более того.
Например, на mutex-ах и condition_variable можно легко сделать "хитрый" thread-pool, который будет автоматически завершать свою работу при отсутствии новых задач. Или сделать другой "хитрый" thread-pool, который будет динамически изменять свой размер в зависимости от количества задач.
И описанный в статье подход позволяет понять, как можно упростить себе решение этих задач на mutex-ах.
Ваши же рассуждения о том, как классно все в MDBX, никак не проливают свет на способы реализации подобных thread-pool-ов без mutex-ов.
Могу предположить, что вы здесь возразите, мол, прикладному программисту не нужно делать свои thread-pool-ы, а кому нужно, тот разберется. На что я позволю себе сделать два упреждающих ответа:
a) мы говорим про C++, здесь даже "прикладной" программист должен уметь написать свой thread-pool. Т.к. стандартных пока нет как класса, а условия у "прикладных" задач на C++ ну очень уж разные;
b) почему вы вообще решили, что речь идет о прикладной разработке? Вы выдумали себе какой-то тезис, не дали себе труда его как-то обосновать, но начали грузить читателей своей эрудицией из совсем другой области. Если вы настолько уверены, что известные вам принципы работы СУБД облегчают реализацию конкурентных приложений на C++, то напишите статью. Я думаю, такая статья будет интересна очень многим (включая меня).
-- (*) В C++ за счет отсутствия сборщика мусора и из-за отсутствия Rust-овского borrow checker-а проблем с конкурентностью больше. Например, реализация персистентных структур данных (в смысле работ Окасаки, а не в смысле сохранения значений во внешней памяти) из-за отсутствия GC более геморойна.
А вот мне, пользователю библиотеки, при ее использовании - уже нет, я как юзер
Т.е. если данную статью читают разработчики библиотек, которым нужна работа с mutex-ами, то ваше мнение, как мнение юзера, они могут смело проигнорировать. Так ведь получается?
Я это к тому, что статья вполне себе конкретная про вполне себе конкретные проблемы. А в комментариях пошли рассуждать как космические корабли должны правильно бороздить просторы большого театра.
Еще можно было бы понять, если бы мутексам в противовес приводили RCU или software transactional memory. Но высокопарные рассуждения про MDBX/SQL...
вместо этого всего продвинутого - народ продолжает дружно долбиться в семафоры, т.к. не умеет иначе.
Скажите, пожалуйста, а при реализации вот этой самой MDBX (т.е. в коде MDBX) можно долбиться в семафоры и атомики? Или, по рекурсии, для реализации MDBX нужна другая MDBX, чуть более низкого уровня?
Речь про ваш конкретный комментарий, который выглядит набором умных слов без какого-либо полезного выхлопа. Ни обозначения проблемы, ни решения. Ничего. Кроме заключения, что здесь нужно бы подумать.
А так как стиль донесения потока сознания в комментариях показался знакомым, то пришлось вспомнить, что вы за персонаж. Когда же вспомнил, то оказалось показательно. Я вам в прошлый раз рассказывал про людей, которые берут проблему, исчезают на время, потом возвращаются с решением. Но вам такие люди не нужны, вы ищете себе подобных, которые наговорят попусту много умных слов, но ничего толкового не придумают. Могут даже и не осознать, какую проблему решают. Вот в точности как с содержимым вашего комментария.
Но программирование и разработка, все-таки, немножко разные вещи.
Так если я и программировать-то не умею, с чего бы мне в разработке понимать...
Блин, вам корона не жмет, трон не высоковат? Только вы здесь настоящий эксперт с опытом.
И в данном конкретном случае (этой конкретной статьи) можно только абстрактно рассуждать.
Да что вы говорите?!!
Потому нет понимания все конкретики задачи и все ее граничных условий.
С случае данной конкретной статьи все предельно понятно. Автор предложил более чем очевидное решение для некоторых частных случаев использования мутексов. Для тех, кому этим приходится заниматься все очевидно, включая достоинства этого подхода и его недостатки.
И нет, изложенное в статье не про решение конкретных задач. Это про то, как упростить себе жизнь если при решении конкретной задачи все-таки пришлось применять мутексы, а не другие подходы (перечень которых был в статье).
Если вы в этом видите возможность только "абстрактно рассуждать", то у меня для вас плохие новости.
Вы ни разу не сталкивались с ситуацией, когда прекрасно построенная многопоточка на мьютексах отлично работает ровно до того момента, пока нагрузка резко не возрастает и плотность обращения к этим данным не превышает некоторую критическую отметку?
Да куда уж мне, я и программировать-то не умею. Это вам любой анонимный эсперт с LOR-а подтвердит.
Я от человека жду собственных мыслей, а не вызубренного учебника.
Вот не надо по второму разу шарманку заводить. Вы и в первый раз не поняли что я вам пытался донести, а уж сейчас даже не буду тратить своего времени.
Полагаю, ерунда, которую вы написали в этом комментарии -- это и есть наглядный пример "рассуждения вслух", которое вы и ждете от "людей с хорошим опытом разработки".
а) это кликбейт в чистом виде; b) претензия на то, что в статье будет описана вот прям "серебряная пуля".
Если вы давно уже нет, поздравляю от всей души, но позволю усомниться такому самоуверенному заявлению :)
А я уже и не сомневаюсь что вы откровенно не умны и не умеете воспринимать информацию. Потому что, во-первых, вам прямо было сказано, что на ваш дурацкий вопрос следует такой же дурацкий ответ. Вы же этот дурацкий ответ воспринимаете всерьез.
И, во-вторых, вот это:
Раз статья вам не пригодилась вежливость требует возвратить вам лучи известной субстанции от благодарного автора
Я не говорил о полезности статьи вообще. "Благодарность" была высказана исключительно за примеры кода в виде картинок. Но вы, в силу своеобразного восприятия реальности выдумали себе ХЗ что.
Про Kaspersky OS можно и не беспокоится. Она явно в надежных руках.
В боевом коде, безусловно, лучше сделать как у вас.
Т.е. ваш код, на который вы ссылаетесь, он не "боевой"? Это типа вы C++ изучали и в процессе изучения экспериментировали для души?
Интересно, интересно. Осталось бы понять зачем вы рассказываете о подходе, который должен облегчить жизнь программиста (который должен писать реальный код для прода), но даете ему в качестве образца то, что для "боевого" применения не предназначено.
Мне кажется, никакого выигрыша в перфомансе от shared_мьютексов нет.
Это зависит от того, как надолго вам нужно захватить расшаренные данные. Если общие данные -- это какой-то развесистый граф, по которому вам нужно пробежаться туда-сюда-обратно, то shared_mutex будет выгоден (не смотря на то, что его захват может быть дороже). Ведь вы все равно на работу с данными потратите сильно больше времени. Но при этом shared_mutex даст возможность одновременно читать общие данные нескольким потокам-читателям.
Если же расшаренные данные -- это пара-тройка int-ов, то да, вопрос открыт.
Вы все еще пишете многопоточку на C++ с ошибками синхронизации?
Уже давно нет. И многократно рассказывали как это делать.
Собственно, на дурацкий вопрос такой же дурацкий ответ. Проблемы с синхронизацией обнаруживаются даже при работе с акторами, без разделяемого состояния вообще, только на обмене иммутабельными сообщениями. В виде livelock-ов, например.
Да и в озвученном подходе с SharedState стоит только ссылке на данные из лямбды протечь куда-нибудь, как приключения не заставят себя ждать.
ЗЫ. За примеры кода, вставленные в статью в виде скриншотов, автору отдельные лучи известной субстанции признательности от благодарного читателя.
Так "не обойтись" или "чушь какая-то"
Вы уж определитесь.
И речь шла не про очереди заявок для thread-pool-а.
Ошибаетесь. Вам тут уже привели пример вашей же MDBX, в которой около 200 применений мутексов.
Подумайте.
Потому что там конкурентность для решения задач СУБД. Если создается, скажем, видеоредактор или прокси-сервер, то конкурентность и там потребуется, но вряд ли она будет такая же, как в случае с СУБД.
Нет.
Вы зафиксировали совсем не то.
Кликабельность != кликбейтность
В том и суть: заголовок претендует на что-то серьезное, а по факту получается такое себе.
Вы, похоже, никогда не слышали выражения "посылать лучи поноса". Вот в данном случае эти самые лучи и были вам отправлены за то, что примеры кода вставлены картинками.
Если суть претензии для все все еще "ХЗ", то хотя бы обратите внимание на:
количество людей, поддержавших мой комментарий;
я не единственный, кто такую претензию озвучил.
Можно и дальше считать меня идиотом, а можно просто сделать выводы.
Уверяю вас, что все замечания, которые вы не смогли адекватно воспринять, были сделаны в максимально корректной форме. Вы даже ни одного грубого слова не найдете.
Если потенциальному пользователю нужно дорабатывать ваш исходник напильником, то это сложно назвать "у меня готова полная реализация SharedState". Она либо не готова, либо не полная.
К тому, что ваш бенефис знаний о подходах из СУБД в комментариях к данной статье является офтопиком. Может быть он был бы уместен, если бы статья пыталась сравнивать разные подходы к решению проблем конкурентности в C++(*). Но нет, она не о конкурентности вообще, она о том, как уменьшить вероятность выстрелить в ногу если mutex-ы все-таки нужны.
Еще одна ваша проблема в том, что вы рассуждаете о сферических конях в вакууме. Нужно нехило так пораскинуть мозгами, чтобы понять, как идею MVCC использовать для решения той или иной задачи, не связанной с хранением данных в БД. А вы не даете никаких намеков на то, как эти самые "только INSERT на каждое изменение" применять в решении тех или иных задач. Только демонстрация собственной эрудиции, не более того.
Например, на mutex-ах и condition_variable можно легко сделать "хитрый" thread-pool, который будет автоматически завершать свою работу при отсутствии новых задач. Или сделать другой "хитрый" thread-pool, который будет динамически изменять свой размер в зависимости от количества задач.
И описанный в статье подход позволяет понять, как можно упростить себе решение этих задач на mutex-ах.
Ваши же рассуждения о том, как классно все в MDBX, никак не проливают свет на способы реализации подобных thread-pool-ов без mutex-ов.
Могу предположить, что вы здесь возразите, мол, прикладному программисту не нужно делать свои thread-pool-ы, а кому нужно, тот разберется. На что я позволю себе сделать два упреждающих ответа:
a) мы говорим про C++, здесь даже "прикладной" программист должен уметь написать свой thread-pool. Т.к. стандартных пока нет как класса, а условия у "прикладных" задач на C++ ну очень уж разные;
b) почему вы вообще решили, что речь идет о прикладной разработке? Вы выдумали себе какой-то тезис, не дали себе труда его как-то обосновать, но начали грузить читателей своей эрудицией из совсем другой области. Если вы настолько уверены, что известные вам принципы работы СУБД облегчают реализацию конкурентных приложений на C++, то напишите статью. Я думаю, такая статья будет интересна очень многим (включая меня).
--
(*) В C++ за счет отсутствия сборщика мусора и из-за отсутствия Rust-овского borrow checker-а проблем с конкурентностью больше. Например, реализация персистентных структур данных (в смысле работ Окасаки, а не в смысле сохранения значений во внешней памяти) из-за отсутствия GC более геморойна.
Вы мне напоминаете героя анекдота: о знал каратэ-до, тайквон-до, айкидо, дзюдо и еще много других страшных слов.
Умных слов много, смысла мало.
Да и вообще лучше быть богатым и здоровым, а не бедным и больным.
Тут бы, конечно, следовало бы выяснить, почему вдруг речь зашла о прикладниках, если автор статьи делает отсылки к Kaspersky OS, но...
...видимо, вы увидели в статье что-то свое. Отсюда и растекание мыслею по древу.
Что-то меня терзают смутные сомнения, что в 1970-х уже были придуманы тот же RCU или, например, lock-free структуры данных.
Простите, но где? MDBX, Berkeley DB, SQL, ACID -- этого в достатке. "Транзакционность памяти" касательно СУБД была.
А вот конкретно RCU или STM в ваших стенаниях что-то не замечал.
Это то, что вы разводите в своих комментариях. Как, например, рассуждения про инженеров и мастеров-сборщиков.
Это такой намек на то, что вы в своих рассуждениях о том, как все прекрасно в MDBX, ушли слишком далеко от темы статьи.
Т.е. если данную статью читают разработчики библиотек, которым нужна работа с mutex-ами, то ваше мнение, как мнение юзера, они могут смело проигнорировать. Так ведь получается?
Я это к тому, что статья вполне себе конкретная про вполне себе конкретные проблемы. А в комментариях пошли рассуждать как космические корабли должны правильно бороздить просторы большого театра.
Еще можно было бы понять, если бы мутексам в противовес приводили RCU или software transactional memory. Но высокопарные рассуждения про MDBX/SQL...
Скажите, пожалуйста, а при реализации вот этой самой MDBX (т.е. в коде MDBX) можно долбиться в семафоры и атомики? Или, по рекурсии, для реализации MDBX нужна другая MDBX, чуть более низкого уровня?
Я здесь вообще не при чем.
Речь про ваш конкретный комментарий, который выглядит набором умных слов без какого-либо полезного выхлопа. Ни обозначения проблемы, ни решения. Ничего. Кроме заключения, что здесь нужно бы подумать.
А так как стиль донесения потока сознания в комментариях показался знакомым, то пришлось вспомнить, что вы за персонаж. Когда же вспомнил, то оказалось показательно. Я вам в прошлый раз рассказывал про людей, которые берут проблему, исчезают на время, потом возвращаются с решением. Но вам такие люди не нужны, вы ищете себе подобных, которые наговорят попусту много умных слов, но ничего толкового не придумают. Могут даже и не осознать, какую проблему решают. Вот в точности как с содержимым вашего комментария.
Так если я и программировать-то не умею, с чего бы мне в разработке понимать...
Блин, вам корона не жмет, трон не высоковат? Только вы здесь настоящий эксперт с опытом.
Да что вы говорите?!!
С случае данной конкретной статьи все предельно понятно. Автор предложил более чем очевидное решение для некоторых частных случаев использования мутексов. Для тех, кому этим приходится заниматься все очевидно, включая достоинства этого подхода и его недостатки.
И нет, изложенное в статье не про решение конкретных задач. Это про то, как упростить себе жизнь если при решении конкретной задачи все-таки пришлось применять мутексы, а не другие подходы (перечень которых был в статье).
Если вы в этом видите возможность только "абстрактно рассуждать", то у меня для вас плохие новости.
Попытки рассуждать вслух вокруг да около.
Да куда уж мне, я и программировать-то не умею. Это вам любой анонимный эсперт с LOR-а подтвердит.
Вот не надо по второму разу шарманку заводить. Вы и в первый раз не поняли что я вам пытался донести, а уж сейчас даже не буду тратить своего времени.
Да что же это происходит?! Про "надо обдумывать" заявляет тот, кто не любит когда люди над его вопросами задумываются на собеседовании.
Полагаю, ерунда, которую вы написали в этом комментарии -- это и есть наглядный пример "рассуждения вслух", которое вы и ждете от "людей с хорошим опытом разработки".
Тогда у вас нет проблем и этот случай не заслуживает внимания.
а) это кликбейт в чистом виде;
b) претензия на то, что в статье будет описана вот прям "серебряная пуля".
А я уже и не сомневаюсь что вы откровенно не умны и не умеете воспринимать информацию. Потому что, во-первых, вам прямо было сказано, что на ваш дурацкий вопрос следует такой же дурацкий ответ. Вы же этот дурацкий ответ воспринимаете всерьез.
И, во-вторых, вот это:
Я не говорил о полезности статьи вообще. "Благодарность" была высказана исключительно за примеры кода в виде картинок. Но вы, в силу своеобразного восприятия реальности выдумали себе ХЗ что.
Про Kaspersky OS можно и не беспокоится. Она явно в надежных руках.
Т.е. ваш код, на который вы ссылаетесь, он не "боевой"? Это типа вы C++ изучали и в процессе изучения экспериментировали для души?
Интересно, интересно. Осталось бы понять зачем вы рассказываете о подходе, который должен облегчить жизнь программиста (который должен писать реальный код для прода), но даете ему в качестве образца то, что для "боевого" применения не предназначено.
Когда int один -- проще.
Но я говорил о нескольких int-ах.
Это зависит от того, как надолго вам нужно захватить расшаренные данные. Если общие данные -- это какой-то развесистый граф, по которому вам нужно пробежаться туда-сюда-обратно, то shared_mutex будет выгоден (не смотря на то, что его захват может быть дороже). Ведь вы все равно на работу с данными потратите сильно больше времени. Но при этом shared_mutex даст возможность одновременно читать общие данные нескольким потокам-читателям.
Если же расшаренные данные -- это пара-тройка int-ов, то да, вопрос открыт.
ХЗ. Я говорю исходя из личного опыта.
Тут вообще большой вопрос -- а зачем тянуть std::function для block-а? Почему бы не сделать так:
Уже давно нет. И многократно рассказывали как это делать.
Собственно, на дурацкий вопрос такой же дурацкий ответ. Проблемы с синхронизацией обнаруживаются даже при работе с акторами, без разделяемого состояния вообще, только на обмене иммутабельными сообщениями. В виде livelock-ов, например.
Да и в озвученном подходе с SharedState стоит только ссылке на данные из лямбды протечь куда-нибудь, как приключения не заставят себя ждать.
ЗЫ. За примеры кода, вставленные в статью в виде скриншотов, автору отдельные лучи
известной субстанциипризнательности от благодарного читателя.