Накатал статью по своему скромному опыту войн с потоками

зумер порвался!

Но ты же понимаешь, что время (единицах измерения СИ) и инструкции в твоих алгоритмах - это разные термины из разных пространств. Вот нет у тебя в системе часов, как таймаут будешь считать? не разбудит прерывание таймера твой уснувший процессор.

тут два анонимуса, я тебе писал про екскаватор. также я тебе писал про java me. вот тебе ява, найди мне там mutex lock с таймаутом. https://docs.oracle.com/javame/8.3/javame-apis.htm

или идинахер, дружочек.

Вот нет у тебя в системе часов, как таймаут будешь считать? не разбудит прерывание таймера твой уснувший процессор.

книжко почитай как процессоры спят и как считается время. неведомо ты чудовище!

у меня даже сессия от твоих постов перестала переключать раскладки!!! и застряла на латинице. пришлось выходить-заходить.

тут два анонимуса

Ну, так и в posix *_timedlock - это опциональная фукция, которой может и не быть.

ну, так и я об этом писал выше как бы. поциент студент же, у него сессия.

процессоры

Процессоры бывают только intel i9-12900, которые не работают без другого процессора для intel me?

Ну, так и в posix *_timedlock - это опциональная фукция, которой может и не быть.

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

вас просили серьезную либу или серьезный язык. в нормальной яве это в либе ЕСТЬ!(и это не просто так, неужто трудно башку включить???). урезанную до предела яву микроедишн для свистков и кофемолок просьба не предлагать.

серьезный

Никто с этим не спорит. И ты серьезный! И современный! И умница! Молодец! Красавец!

Процессоры бывают только intel i9-12900

спросите у интела и других производителей - какие бывают процессоры… и побожитесь им, что время нельзя считать пока проц типа «спит». а лучше посмотрите еще раз как «спят» процы. может поймете всю глубину своей наивности.

просьба не предлагать

собственно чтд. иксперты икспертно икспертируют и идутнахер.

собственно чтд. иксперты икспертно икспертируют и идутнахер.

вы видимо эксперт по жава лимитед едишн свистоперделкам, и потому таймауты у мьютексов вас просто подкосили и мы уже страницы две мусолим очевидное.

но жизнь сложней лимитед эдишн явы и ваших свистоперделок.

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

зы: а что это форум такой тормозной стал? раньше все летало, теперь все стоит.

Хабр - не торт. Статья читается тяжело, ничего нового и умного я в ней не увидел. Не очень понятно на кого она ориентирована. Студентам которые только начали вникать в проблемы многопотока, она только мозги запудрит, а те кто хоть сколько-то занимался многопотоком и так знают всё озвученное не хуже автора. И вообще проблема давно решена и напороться на неё можно только если очень постараться. И вообще для очень больших данных и объёмов параллельности есть map reduce.

На по настоящему высоконагруженных системах нас не сильно беспокоят нагрузки, не меняющие вычислительную сложность. Т.е. если надо ткнуть в кластер не 100 машин, а 200 и при этом рост от нагрузки линейно масштабируется то нас это не особо беспокоит. Там нас больше волнует насколько эффективно задачи можно параллелить, потому что если мы можем 99% времени эффективно использовать все 200 машин то это одно, а когда у нас 50% времени всё 2 машины лопатят, а остальные ждут когда же оно долопатит, то это совсем другое.

Плюсую

Ну когда ты с пользовательскими данными работаешь, а не ОС которая бесконечно by design должна работать, то за таймауты надо (много самоцензуры) делать. Потому что обычно пусть лучше всё виснет или вообще падает нафиг, чем в БД потеряется запись или принципиально не может исполниться сложный запрос у которого время на исполнение больше вашего таймаута.

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

не. таймаут обычно выполняет две функции:

1. защитную функцию.
2. запуск фоновой активности

защитная - некий обьект занят слишком долго, это говорит о том, что с тем, кто его схватил, явно что то не так. «слишком долго» это такой интервал, внутри которого нормальные операции должны гарантированно исполняться. то есть например это 10 гарантированных(максимально долгих) длительностей операции.

тогда ты можешь выскочив по таймауту сделать некое логирование и опять попытаться залочить этот обьект.

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

Тут да, правильно пишешь. Но использовать таймаут с надеждой на то что что-то там просто «залагало» и всё нормально посчитало никак нельзя. Если таймаут сработал то либо с данными что-то не так, либо с кодом.

Я хотел то же самое сказать. Вообще, статья выглядит как попытка прокачать свой авторитет и набить себе цену (в связи с Макака ищет работу, C, Python, JS, либо челендж в опенсорсе на C++).

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

Я хотел то же самое сказать. Вообще, статья выглядит как попытка прокачать свой авторитет и набить себе цену (в связи с Макака ищет работу, C, Python, JS, либо челендж в опенсорсе на C++)

Ну так есть замечания по этому поводу? Типа «слишком палевно, тоньеш надо»? Разве каждое второе животное в IT не пытается набить себе цену, например, упоминая в резюме названия всех программ, которые оно запускало хотя бы один раз? Или упоминание blockchain в резюме — как ты думаешь, хотя бы один из таких людей писал элиптическую криптографию или распределенную сеть? Или же твоя претензия к тому, что я качаю авторитет не по смузихлебским канонам, что бросается в глаза? Желательно тогда рекомендации по этому поводу.

Что толку в подтверждении получения, если получатель мог в следующую микросекунду свалиться в сегфолт, быть убит админом или оказался на обесточенном узле сети?

Отказоустойчивость — это проблема иного порядка. Давай не мешать все в кучу. Для отказоустойчивости не помогут ни агенты, ни каналы, ни сообщения сами по себе — это лишь мелкие вспомогательные штуки, которые могут быть использованы при разработке отказоустойчивой, которая, к тому же, на проверку может оказаться нихрена не отказоустойчивой.

Нет общего решения, чтобы отличить сбой от очень долгого ответа.

рандеву на сообщениях делается так. ожидающий начала рандеву ждет асинхронной мессаги от другого треда - «вошел_в рандеву», получив мессагу ожидающий делает, что надо и посылает мессагу - «рандеву_завершено». то есть рандеву начинается с посылки одним - «начало» и завершается посылкой другим - «конец».

Ты подразумеваешь, что подо всем этим лежит операционная система, которая за тебя решила проблему гарантий доставки. То есть, гарантирует, что сообщение отправителя не уйдет безвозвратно в вакуум. Если это делается без ОС на уровне разделяемой памяти, то это уже то, что требовалось доказать. Это первый момент, отправитель должен знать, что его сообщение кто-то увидит.

Второй момент, аналогичный — как получатель узнает, что его подтверждение о получении дошло до отправителя и отправитель не завис навечно? Либо разделяемая память на уровне процесса (как в Erlang), либо разделяемая память на уровне ОС, либо бесконечные запрос-ответы на сетевом уровне.

То, что ты описываешь — это алгоритм, по которому синхронно доставляет сообщения тот же Erlang, но для этого ему внутри пришлось сделать не совсем очевидную магию, которая скрыта от пользователя — это очереди сообщений в разделяемой памяти, сообщения в которые добавляются в lock-free режиме. Собственно, вот тебе и весь фундамент «рандеву» — аппаратные блокировки на разделяемой памяти. А нифига не «асинхронные сообщения» — это уже на lock-free доступе к разделяемой памяти построены асинхронные сообщения. И уже на этих конкретных асинхронных сообщениях строятся синхронные сообщения.

Никто не будет читать статьи, написанные владельцем столь изысканного слога и словарного запаса. Противно. Автору лучше работать руками, ногами или задницей, в конце концов, но молча. Не стоит мусорить в и так убогом рунете

Как мило. Смотри, смузи не поперхнись.

Возникла мысль, что автору нужно просто взять Scala и прекратить мучать себя питоном.
(Легко сказать, да где ж её взять. Чтоб реально на работе была она, а не питон.)

Ну идея была в том, что «никто не может — а я смог». Я в предыдущей статье на английском так и писал, что на норм языке многопоточность кто угодно может написать, а ты попробуй на куске дерьма это сделать.

И вообще проблема давно решена и напороться на неё можно только если очень постараться. И вообще для очень больших данных и объёмов параллельности есть map reduce

Как решена? Я что-то пропустил? По-моему, есть только костыли разных сортов, но «решения всех проблем» я что-то не заметил. Map Reduce поможет тебе посчитать количество слов, но что делать, если нужно жирная семантика со сложными взаимными логическими связями? Банальные реляционные join-ы на map-reduce больно делать.

Я понимаю, что нынче к этому подходят как «не нужно» и стараются делать все данные плоскими и самодостаточными — что выливается в рост объема хранимой информации на порядок, ну всякие там JSON безсхемовые и прочий треш. Но банковские транзакции на таком просто не сделаешь, при всём желании. Одна из эпичных криптовалютных бирж была построена на монге и позволяла double spend на уровне монги, что не имело никакого отношения к double spend самой крипты.

Вопросы распределенных систем с согласованностью данных — это вообще дремучий лес. Как я писал на хабре, во всей индустрии только три софтины позволяют добиться строгой согласованности при отказойстойчивости и не совсем уж помойной производительности. Помойной — это уровня «один запрос в 5 секунд», как было бы в наивной реализации Paxos.

Так что проблема «решена», только потому что существующие решения «good enough» и просто никто не парится разработкой новых. Потому что зачем кому-то стараться разрабатывать софт ради интересов амазона или гугла?

Потому что обычно пусть лучше всё виснет или вообще падает нафиг, чем в БД потеряется запись или принципиально не может исполниться сложный запрос у которого время на исполнение больше вашего таймаута

Да, я тоже таймауты применяю в основном как отладочную фичи. То есть, в отладочном билде таймауты снижаю на порядки, чтобы при подвисании они тригерились и вываливался затык в логи.

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

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

Нет общего решения, чтобы отличить сбой от очень долгого ответа

Так он и не нужен, долгий ответ = сбой.

что это форум такой тормозной стал?

Apple опять за свое взялась. Вынуждает Макскома обновить айфон.

долгий ответ = сбой

мдее, а ещё и статьи взялся писать. тухлятина

как получатель узнает, что его подтверждение о получении дошло до отправителя и отправитель не завис навечно?

а это не нужно знать. архитектура нормальной распределенной системы должна быть малосвязной. «подтверждения» на уровне ос или каналов не нужны. если ВДРУГ нужны подтверждения(что говорит о высокой связности двух разнесенных подсистем или узлов) - это имеет смысл делать на логическом уровне. то есть посылкой уведомляющих мессаг.

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

а это не нужно знать

ведь иксперты и так всё знают.

ведь иксперты и так всё знают.

особенно иксперды, старающиеся себя не афишировать. с «замазанными грязью номерами», и «потерявшие паспорт» по дороге к маме в среднюю азию.

не знал, что ты из средней азии. колоса подкочал перед поездкой, дружочек?

колоса подкочал перед поездкой, дружочек?

у меня паспорт есть. а ты мигрант с перебитыми номерами - не пойми кто.

что делаешь тут?

ты не очень умный. да и петросян из тебя не очень.

ты не очень умный.

ну знаете ли…умных к умным, а меня к вам.

Как решена?

Решена и всё тут.

Я что-то пропустил?

Последние лет 50 так развития компьютеров. Там говорят массивы семафоров придумали и условные выражения вроде как тоже догадались что можно использовать.

По-моему, есть только костыли разных сортов, но «решения всех проблем» я что-то не заметил.

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

Я понимаю, что нынче к этому подходят как «не нужно» и стараются делать все данные плоскими и самодостаточными — что выливается в рост объема хранимой информации на порядок, ну всякие там JSON безсхемовые и прочий треш. Но банковские транзакции на таком просто не сделаешь, при всём желании. Одна из эпичных криптовалютных бирж была построена на монге и позволяла double spend на уровне монги, что не имело никакого отношения к double spend самой крипты.

Не занимаюсь разработкой СУБД, но мой опыт подсказывает что проблема там в основном что СУБД большие, фичастые и полны легаси говнокода, а в нормальную микроархитектуру люди так и не научились.

Вопросы распределенных систем с согласованностью данных — это вообще дремучий лес. Как я писал на хабре, во всей индустрии только три софтины позволяют добиться строгой согласованности при отказойстойчивости и не совсем уж помойной производительности. Помойной — это уровня «один запрос в 5 секунд», как было бы в наивной реализации Paxos.

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

Так что проблема «решена», только потому что существующие решения «good enough» и просто никто не парится разработкой новых. Потому что зачем кому-то стараться разрабатывать софт ради интересов амазона или гугла?

А это уже экономический вопрос о целесообразности.

архитектура нормальной распределенной системы должна быть малосвязной. «подтверждения» на уровне ос или каналов не нужны. если ВДРУГ нужны подтверждения(что говорит о высокой связности двух разнесенных подсистем или узлов) - это имеет смысл делать на логическом уровне. то есть посылкой уведомляющих мессаг

Я тебе половину статьи пытался пояснить, что целый класс задач при помощи распределенных систем в принципе нельзя решить.

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

Она гарантирована именно потому, что работает на разделяемом состоянии. От того, что это состояние реализует система, а не ты, ничего не меняется. Можешь хоть в RabbitMQ хранить это состояние и общаться с ним асинхронными сообщениями — это все равно будет синхронное разделяемое состояние, с большим числом (бесполезных) оберточек вокруг него.

Там говорят массивы семафоров придумали и условные выражения вроде как тоже догадались что можно использовать

Ага, ну-ну, это «прогресс» уровня «все задачи уже давно научились решать на ассемблере». Так не подскажешь, почему индустрия пишет на питоне и JS? Чот я в этих языках условные выражения и массивы семафоров не вижу.

потому что на каждую отельную проблему есть своё решение и вообще абстракции в голове надо фиксить под реальность

Очнись: вся индустрия использует безумно неэффективное единственное аппаратное решение под абсолютно все проблемы. Почему это не делают новый процессор под новую задачу?

Не занимаюсь разработкой СУБД, но мой опыт подсказывает что проблема там в основном что СУБД большие, фичастые и полны легаси говнокода, а в нормальную микроархитектуру люди так и не научились.

Проблема заключается в том, что либо производительность, либо логика. А вместе сразу чот не получается их совместить. У меня есть соображения по поводу качественного скачка в этом направлении, но всем все равно пофиг — потому что индустрия будет продолжать искать гвозди под свой единственный молоток.

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

Многопоточные алгоритмы простые, по-твоему? Давно смотрел на какой-нибудь lock-free односвязанный список?

Она гарантирована именно потому, что работает на разделяемом состоянии.

я тебе честно скажу… я давно в этом деле, но то что ты говоришь - понимаю с трудом. термин «разделяемое состояние» вообще режет ухо, и является скорей буззвордом, чем существенным понятием.

у меня вот впечатление, что ты какой-то учитель информатики, и пытаешься дядькам из софтоверной индустрии, читать лекции не пойми о чем.

в многопотоке «гарантированная доставка» обеспечивается по сути тем, что каналы передачи сообщений, находятся в памяти, и потеря данных невозможна, это вам не физическая сеть,

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

про твое «разделяемое состояние» и знать ничего не хочу.

много букв написано и копий сломано, но если метко подытожить, то кг/ам или нет?

Ага, ну-ну, это «прогресс» уровня «все задачи уже давно научились решать на ассемблере». Так не подскажешь, почему индустрия пишет на питоне и JS? Чот я в этих языках условные выражения и массивы семафоров не вижу.

Условные выражения ты видишь, погугли что это, будешь долго смеяться, когда поймёшь какое ограничение стоит у задачи про 3 курильщиков, которую ты вспомнил в статье, чтобы у неё были проблемы. Касательно вопроса почему - потому что так дешевле. Труд программиста дорог и дешевле купить лишних компов, чем лишних программистов.

Очнись: вся индустрия использует безумно неэффективное единственное аппаратное решение под абсолютно все проблемы. Почему это не делают новый процессор под новую задачу?

Весь вопрос в деньгах. Делают то что дешевле.

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

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

Многопоточные алгоритмы простые, по-твоему?

Нет, сложные. В плане они сложнее чем однопоточные. Но это та сложность, от которой не уйти.

Автор, а почему число возможных сценариев выполнения в первом примере оказалось 4**4, т.е 256? Откуда это взялось?

Автор, а почему число возможных сценариев выполнения в первом примере оказалось 4**4, т.е 256? Откуда это взялось?

Накатал статью по своему скромному опыту войн с потоками (комментарий)

кг/ам или нет?

Как я понял, автор сам не в курсе зачем он это сделал и кто его пользователи. Он сразу хочет, чтобы его в пайтонкор приняли или как минимум, чтобы два раза ку при его заходе на ЛОР.

Поэтому ответ очевиден.

Пусть у нас два потока по две команды. Пронумеруем команды первого 1, 2, а второго - a, b. Возможные последовательности:

12ab 1a2b 1ab2 ab12 a1b2 a12b

ни разу не 2**2.

Накатал статью по своему скромному опыту войн с потоками

А примеры на Python использования API имеется?
Какой профит от него?