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

Очередь это оно и есть.

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

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

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

Очередь это оно и есть

Ну да, если брать всякие RabbitMQ, то это по сути база данных. На Redis еще вроде очереди сообщений делают.

А где ты видишь слово «очередь» в моей цитате?

я вообще не понимаю зачем механизм рандеву приплетать как некий альтернативный «общий подход».

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

Вот ты два самых популярных решения и назвал, а так почти любой паб/саб подойдет, можно на постгресе попробовать запилить) у него есть пабсаб с ограничением на длину сообщения)

А еще есть ЯП заточенные под модель акторов, elixir например

Вместо картинки про Erlang и «подтверждение принято» - спасибо что она на русском - можно было про двух генералов, оно как-то острее ощущается. Ещё надо было написать про принцпип двух из трёх в распределённых системах

Статья была не про распределенные системы, а про универсальные принципы. Асинхронные акторы имеют одинаковые проблемы в многопоточном, многозадачном, и распределенном исполнении — именно эта ситуация некоторыми людьми переворачивается как «акторы легко масштабируются до распределенной сети». Я в статье попытался доказать, что для отдельных применений эти проблемы очень серьезные и решаются только отказом от асинхронных акторов и распределенности.

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

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

ну то есть у тебя примеры получились «мороженное, ананас, и ядерная бомба».

Дальше, было бы неплохо описать два вида СУБД - с пессимистичной и оптимистичной блокировками (это из моего века динозавров, сейчас ещё что-нибудь придумали), и как диспетчер разрешает клинчи в них

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

А для неинтрузивного логирования можно попробовать rr

rr очень круто, без базара, но оно не умеет работать сразу с несколькими процессами.

афтар учи матчасть!

ты чего такой агрессивный?

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

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

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

ты сейчас описал один-в-один поведение каналов в го.

я вообще не понимаю зачем механизм рандеву приплетать как некий альтернативный «общий подход»

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

А еще есть ЯП заточенные под модель акторов, elixir например

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

есть еще разные фрейморки, реализующие акторную модель. Akka, например, в Java или Ergo Framework в Golang

каналы в го - это обычный рингбуфер и интерпретировать его как очередь ничто не мешает.

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

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

и никакого подтверждения там нет

и быть не может. это уже вопрос к логике работы двух акторов.

А сделали они это потому, что синхронность и детерминированность рандеву имеет свои преимущества над асинхронными очередями.

рандеву слишком специфическая вещь и легко эмулируется асинхронными очередями.

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

кейс это нужный, но не далекий от всеобщности.

не более чем теоретик многотреда

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

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

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

и никакого подтверждения там нет

и быть не может. это уже вопрос к логике работы двух акторов

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

Чего-нибудь типа обычной очереди должно хватить.

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

из каких обьектов синхронизации делается такая очередь

Например https://clojure.org/reference/agents.

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

• про ранее обнаружение - я не понял и счёл, что это что-то, о чём я не знаю. В firebird (или в оракле, не помню точно), гибридный алгоритм с блокировками и оптимизмом, я думал, ты про эту гибридность, а оказывается это вот про что.
• тогда rr, под которым запускается qemu. Где-то видел статью про это.

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

под капотом там мьютекс и критическая секция.

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

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

рандеву слишком специфическая вещь и легко эмулируется асинхронными очередями

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

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

Да, механизм дает свободу в применении, и некоторые из применений — синхронный вызов функции и сериализация доступа к разделяемому ресурсу по акторному принципу.

В firebird (или в оракле, не помню точно), гибридный алгоритм с блокировками и оптимизмом, я думал, ты про эту гибридность, а оказывается это вот про что

Ой, а тут уже я не понимаю, о чем речь.

тогда rr, под которым запускается qemu. Где-то видел статью про это

Весело. Но может сработать.

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

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

Спасибо, что и сюда дублируете.

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

совсем ты крышею поехал, нельзя тебе в многотред…

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

и усьо! естественно они блокируются, пока ждут мессаг. и никаких подтверждений не нужно тут естессно.

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

Пф-ф-ф: взять из аккаунта a 100$ и положить их в b, взять из аккаунта b 100$ и положить их в аккаунт a. Да, они взаимозависмы, и прекрасно вычисляемы при этом. Что характерно, результат этих операций не зависит от их порядка.

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

таймаут у мьютексов

сразу видно иксперта.

любая система с таймаутами это СРВ уже, а к СРВ совсем другие требования, дружочек.

Насколько я помню, в Оракле есть блокировки схемы. При общем оптимизме транзакции такая блокировка накладывается сразу, и если её нельзя наложить, то ничего и не будет работать. В Firebird тоже версионная модель, но некоторые виды конфликтов выявляются «через ясновидение», поверх границ транзакций. Деталей не помню.

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

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

даже не стоит пытаться
Никто
задницей
убогом рунете

Уже каникулы начались?

Уже каникулы начались?

Очень хочу на каникулы. Любые!

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

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

Перечитал старую статью https://habr.com/ru/post/481782/

Возникла мысль, что автору нужно просто взять Scala и прекратить мучать себя питоном.

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

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

Ого комплексы! Это тебе к доктору быстро надо, едатель одного сникерса на двоих. Гордиться нищетой и гопноватостью – это диагноз. Надеюсь, твои дети тоже будут нищими, будут есть одну котлету на двоих, не получат никакого образования, будут втихаря завидовать нормальным детям и гордиться тем, что они потомки нищего гопника и в детстве ели одну морковку на двоих. Это буде логично.

любая система с таймаутами это СРВ уже, а к СРВ совсем другие требования, дружочек.

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

для например posix threads, которые любая маломальски приличная ос старается реализовать, для совместимости с си софтом, для мьютексов это метод - pthread_mutex_timedlock.

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

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

легко встать в бесконечное ожидание и выйти из него - способа нет.

Кто-то говорил, что «этого в принципе не существует».

Кто-то говорил, что «этого в принципе не существует».

как не существует? и кто это говорил??? берешь мьютекс и зацикливаешься навсегда. или забыл отдать,.. или не забыл отдать, но отдаешь не всегда(например анлок под условным оператором), да их тыщи способов то!

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

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

без таймаутов, это треш полный

так я ж об этом и говорю. java со своим synchronized это по мнению икспертов - треш и угар, да.

поскольку можно легко встать в бесконечное ожидание и выйти из него - способа нет

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

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

уверен, у тебя не получиться. инфа 100%

вот чтобы этого не было - и вводятся таймауты.

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

так я ж об этом и говорю. java со своим synchronized это по мнению икспертов - треш и угар, да.

найди хоть одну реализацию мьютексов без таймаутов. ссылочку на либу,pls… только на реальную либу или ось, а не творчество какого-нибудь погромиста c гитхаба.

pthread_

Вспомнил еще: ничего, кроме posix-тредов, не существует.

Вспомнил еще: ничего, кроме posix-тредов, не существует.

покажи мьютексы без таймаутов, не томи. ссылку давай

покажи мьютексы без таймаутов

Где показать, в pthread?

так я ж об этом и говорю. java со своим synchronized это по мнению икспертов - треш и угар,

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

и знаешь как советуют?

https://stackoverflow.com/questions/1194606/how-to-detect-deadlock-timeout-in-synchronized-block

You can use a java.util.concurrent.Lock instead of the intrinsic Object locks. RentrantLock without fair ordering has the same basic behaviour and semantics as an intrinsic lock. There is a method tryLock that takes a timeout parameter:

ааахахаха. не пользуйтесь внутренним локом, берите лок из библиотеки… у него есть таймаут… упс.

то есть лок с таймаутом есть даже в явской бибилиотеке… ну ты поищи где его нет, поищи… :)))

найди хоть одну реализацию мьютексов без таймаутов

в любой posix совместимой без поддержки real time extensions?

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

в любой posix совместимой без поддержки real time extensions?

в какой хошь. в яве мы уже таймуты нашли… давай не найдем где-нить.

real time

Какой еще реалтайм? У нас тут счетчики тактов! Да не остановиться тактовый генератор!

хоспади. так там вопрос задает такой же иксперт как ты, «у меня тут тред перестаёт работать, надо костыль, имя сестра имя!». наверное ты тот тред и создал ))

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

между прочим в первых librt не было *timed* никаких. А потом сделали, именно что бы вот тому самому 1003b (точно не помню) соответствовать, а не для того что бы васян как ты говноблоки отлаживал, ферштейн?

вот смотри, управляешь ты ковшом с расплавленным металом

ссылку давай, не тренди языком.

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

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

в яве есть

java me api. поищи, наверняка там должны быть.

современный

Это термин из реалтайма? Сколько это в тактах процессора или количестве инструкций выполненных с рождества Тьюринга или Беббиджа?

Это термин из реалтайма?

чувак. у меня нет времени читать твои рефлексии про «рилтайм» и «огнедышащий ковш экскаватора».

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

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