Покрасить все корневые объекты (стек и глобальные переменные) в серый.
Выбрать серый объект из набора серых объектов и пометить его как чёрный. (Из какого набора серых объектов? Мы же только что ВСЕ объекты покрасили в серый. Т.е. выбрать рандомно объект?)
Все объекты, на которые указывает чёрный объект, пометить серым. Это гарантирует, что сам объект и объекты, на которые он ссылается, не будут выброшены в мусор. (Так, мы покрасили ОДИН объект из ВСЕХ черным. Дальше мы все объекты, на которые указывает этот черный объект, помечаем серым. То есть на этом шаге мы не делаем НИЧЕГО)
Если в графе остались серые объекты, вернуться к шагу 2. (Естественно они ОСТАЛИСЬ, только если объект не был единственным в этом "наборе". При этом если возможна ситуация, когда серый объект указывает на черный, получаем бесконечный цикл)
Итого, логически доказано, что алгоритм А) красит все объекты в серый цвет. Б) затем рандомно в цикле выбирает по одному объекту и красит их в черный цвет, пока все объекты не становятся черными. Тогда почему сразу все в черный цвет не покрасить уже на первом шаге? Статья как будто chatGPT написана
Стек горутины не использует стек треда напрямую. Стек горутины — это выделяемая и управляемая память в heap'е, а не стандартный стек ОС. Так что 1 ГБ горутины не должен уместиться в 2 МБ стека треда — потому что он туда и не помещается. Он живёт отдельно.
Простое описание того, как работает go - планировщик по большому счету смысла не имеет. Если бы я брал человека на работу и он он бы рассказал вот эту статью, я бы затем спросил: «ну и что?». Ну вот работает он так, ну и что? Горутины в go в чем - то лучше/хуже корутин в том же python? В kotlin? В js? Зачем go? Как - то все сложно тут сделали. А зачем GOMAXPROCS? А что, горутины путешествуют между потоками? А в других языках? Все познается в сравнении.
Сама суть то я считаю, простая. Конечно, по статье можно косвенно об этом судить, но вот это G,M,P понимание не особенно для рядового программиста важно. Многие пытаются на собесах про это G,M,P, я думаю, вспомнить, при этом за деревьями леса не видя
Статью было бы вернее назвать как - то вроде «контейнеры для самых маленьких», а не так. Подумал, что тут про какие - то новшества, а тут просто про контейнеры в целом
Насчет «длины токенов» соглашусь - если посмотреть, сколько какая - нибудь превью картинка с какого - нибудь интернет - каталога занимает. А вот «stateless” для аутентификации пользователя мало подходит. Особенно в глазах бизнеса. Помню, был такой кейс на работе - тимлид решил внедрить jwt - токены с access/refresh. Я сразу сказал, что будут проблемы с разлогиниванием и выдачей новых прав. Бизнес такой «eventual consistency” не поймет. На что он мне - «все будет в порядке, под мою ответственность». Честно признаюсь, что смеялся над ним, когда встал такой кейс и он попытался объяснить модность jwt токенов бизнесу. Потом переписывал все на сессии с редисом в авральном режиме под угрозой увольнения. «Знаете, словами «а я же говорил» этого не передать»
Вопрос в том, а для чего нужна ревизия и не сможет ли с ней справится БЭМ. Если будет обнаружен баг и БЭМ сможет его найти, то ревизия не нужна. Также как и если нужно будет внедрить новый функционал и БЭМ сможет это сделать. А так даже во время ревизии чужого кода, созданного человеком часто спрашиваю у БЭМ - «можешь доходчиво объяснить, что тут делается и зачем, отрефакторить код или объяснить, почему такой - то баг?». И БЭМ часто выдает очень даже неплохой результат
А что понимается под «транзакционная модель оракла куда надёжнее»? Это когда оракл вообще не соответствует стандарту SQL в плане транзакций, т.к. допускает аномалии сериализации на уровне Serializable?
Вопрос - а почему феномены «Неповторяющееся чтение» и «Фантом» разделены? Ведь по сути в случае добавления строк также возникает «Неповторяющееся чтение»?
Вообще, если исходить из жаднойлогики, то кажется, что если аномалий/феноменов будет меньше, то надежность/консистентность будет выше и это лучше. Но тогда можно было просто оставить один уровень - Serializable и одно предложение - "A serializable execution is defined to be an execution of the operations of concurrently executing SQL-transactions that produces the same effect as some serial execution of those same SQL-transactions" во всем параграфе Стандарта про уровни изоляции. Но если смотреть в общем, дедуктивно, Стандарт предполагает некий Tradeoff между производительностью и надежностью на каждом уровне. А защита от каждой аномалии явно предполагает какие - то доп. механизмы, может и незначительно, но снижающие производительность. Слабо верится, что PostgreSQL смогли отказаться от уровня read uncommitted не потеряв при этом совсем в производительности.
Так что вполне возможно, что Стандарт как раз - таки подразумевает, чтобы феномены были на определенных уровнях изоляции. И вполне возможно, что кто - нибудь придет в PostgreSQL и скажет - "Мне для задачи нужен именно уровень Read Uncommitted. Так, его тут нет. И это не есть хорошо"
Интересный момент. 1) Стандарт определяет, каких аномалий на каком уровне точно быть не должно(not possible). И если они присутствуют - значит, реализация уровня не соответствует стандарту, как в Oracle 2) Стандарт определяет, какие аномалии могут присутствовать на уровне изоляции (possible). Значит ли это по аналогии, что если на соответствующем уровне изоляции аномалия присутствовать не может - то реализация также не соответствует Стандарту? (-: Стандарт: The isolation level specifies the kind of phenomena that can occur during the execution of concurrent SQL-transactions
Надо заметить, я нигде в тексте не сказал, что Postgresql ведёт себя не согласно Стандарту. Я только сказал, что Mysql и SQLServer ведут себя согласно Стандарту, а в PostgreSQL этот уровень соответствует уровню Read Commited.
BEGIN;
UPDATE accounts
CROSS JOIN ( SELECT 1
FROM accounts
WHERE user_id = 1
HAVING SUM(amount) >= 2000 ) as criteria
SET amount = amount - 1000
WHERE id = 10
AND amount >= 1000;
Да, именно так и есть - к примеру, инвест фонды Кремниевой долины - главное, проработать свою идею так, чтобы она понравилась инвестору, а уж взлетит она или нет - это дело десятое. Сотни миллионов долларов в проекты, которые порой вообще ни доллара дохода не принесли. Ответвления по всему миру - и в России тоже были в виде Silicon Valley Insiders от венчурных инвесторов Yellow Door, к примеру.
@AlexeyK77Ну вообще же ребята неверно. Откуда только что берете? Во - первых, не "Phantom read", а "Phantom". Это уже потом выводится, что "Phantom" это "read" Во - вторых, "NON-repeatable read" это про Update/Delete. "Phantom" это "INSERT" Все эти определения идут от Стандарта ISO/IEC 9075, согласно нему(стр84): P2 (‘‘Non-repeatable read’’): SQL-transaction T1 reads a row. SQL-transaction T2 then modifies or deletes that row P3 (‘‘Phantom’’): SQL-transaction T1 reads the set of rows N that satisfy some . SQL-transaction T2 then executes SQL-statements that generate one or more rows
Рассмотрим алгоритм логически, по шагам:
Покрасить все корневые объекты (стек и глобальные переменные) в серый.
Выбрать серый объект из набора серых объектов и пометить его как чёрный.
(Из какого набора серых объектов? Мы же только что ВСЕ объекты покрасили в серый. Т.е. выбрать рандомно объект?)
Все объекты, на которые указывает чёрный объект, пометить серым. Это гарантирует, что сам объект и объекты, на которые он ссылается, не будут выброшены в мусор.
(Так, мы покрасили ОДИН объект из ВСЕХ черным. Дальше мы все объекты, на которые указывает этот черный объект, помечаем серым. То есть на этом шаге мы не делаем НИЧЕГО)
Если в графе остались серые объекты, вернуться к шагу 2.
(Естественно они ОСТАЛИСЬ, только если объект не был единственным в этом "наборе". При этом если возможна ситуация, когда серый объект указывает на черный, получаем бесконечный цикл)
Итого, логически доказано, что алгоритм А) красит все объекты в серый цвет. Б) затем рандомно в цикле выбирает по одному объекту и красит их в черный цвет, пока все объекты не становятся черными. Тогда почему сразу все в черный цвет не покрасить уже на первом шаге? Статья как будто chatGPT написана
Стек горутины не использует стек треда напрямую. Стек горутины — это выделяемая и управляемая память в heap'е, а не стандартный стек ОС. Так что 1 ГБ горутины не должен уместиться в 2 МБ стека треда — потому что он туда и не помещается. Он живёт отдельно.
Простое описание того, как работает go - планировщик по большому счету смысла не имеет. Если бы я брал человека на работу и он он бы рассказал вот эту статью, я бы затем спросил: «ну и что?». Ну вот работает он так, ну и что? Горутины в go в чем - то лучше/хуже корутин в том же python? В kotlin? В js? Зачем go? Как - то все сложно тут сделали. А зачем GOMAXPROCS? А что, горутины путешествуют между потоками? А в других языках? Все познается в сравнении.
Сама суть то я считаю, простая. Конечно, по статье можно косвенно об этом судить, но вот это G,M,P понимание не особенно для рядового программиста важно. Многие пытаются на собесах про это G,M,P, я думаю, вспомнить, при этом за деревьями леса не видя
Переусложнено
Статью было бы вернее назвать как - то вроде «контейнеры для самых маленьких», а не так. Подумал, что тут про какие - то новшества, а тут просто про контейнеры в целом
Насчет «длины токенов» соглашусь - если посмотреть, сколько какая - нибудь превью картинка с какого - нибудь интернет - каталога занимает. А вот «stateless” для аутентификации пользователя мало подходит. Особенно в глазах бизнеса. Помню, был такой кейс на работе - тимлид решил внедрить jwt - токены с access/refresh. Я сразу сказал, что будут проблемы с разлогиниванием и выдачей новых прав. Бизнес такой «eventual consistency” не поймет. На что он мне - «все будет в порядке, под мою ответственность». Честно признаюсь, что смеялся над ним, когда встал такой кейс и он попытался объяснить модность jwt токенов бизнесу. Потом переписывал все на сессии с редисом в авральном режиме под угрозой увольнения. «Знаете, словами «а я же говорил» этого не передать»
Вопрос в том, а для чего нужна ревизия и не сможет ли с ней справится БЭМ. Если будет обнаружен баг и БЭМ сможет его найти, то ревизия не нужна. Также как и если нужно будет внедрить новый функционал и БЭМ сможет это сделать. А так даже во время ревизии чужого кода, созданного человеком часто спрашиваю у БЭМ - «можешь доходчиво объяснить, что тут делается и зачем, отрефакторить код или объяснить, почему такой - то баг?». И БЭМ часто выдает очень даже неплохой результат
Ну да, хотя по сути и там, и там чтение не повторилось. Избыточность? И можно ли назвать удаление - "изменением"?
А что понимается под «транзакционная модель оракла куда надёжнее»? Это когда оракл вообще не соответствует стандарту SQL в плане транзакций, т.к. допускает аномалии сериализации на уровне Serializable?
Вопрос - а почему феномены «Неповторяющееся чтение» и «Фантом» разделены? Ведь по сути в случае добавления строк также возникает «Неповторяющееся чтение»?
Вообще, если исходить из жадной логики, то кажется, что если аномалий/феноменов будет меньше, то надежность/консистентность будет выше и это лучше. Но тогда можно было просто оставить один уровень - Serializable и одно предложение - "A serializable execution is defined to be an execution of the operations of concurrently executing SQL-transactions that produces the same effect as some serial execution of those same SQL-transactions" во всем параграфе Стандарта про уровни изоляции. Но если смотреть в общем, дедуктивно, Стандарт предполагает некий Tradeoff между производительностью и надежностью на каждом уровне.
А защита от каждой аномалии явно предполагает какие - то доп. механизмы, может и незначительно, но снижающие производительность. Слабо верится, что PostgreSQL смогли отказаться от уровня read uncommitted не потеряв при этом совсем в производительности.
Так что вполне возможно, что Стандарт как раз - таки подразумевает, чтобы феномены были на определенных уровнях изоляции. И вполне возможно, что кто - нибудь придет в PostgreSQL и скажет - "Мне для задачи нужен именно уровень Read Uncommitted. Так, его тут нет. И это не есть хорошо"
Интересный момент. 1) Стандарт определяет, каких аномалий на каком уровне точно быть не должно(not possible). И если они присутствуют - значит, реализация уровня не соответствует стандарту, как в Oracle
2) Стандарт определяет, какие аномалии могут присутствовать на уровне изоляции (possible). Значит ли это по аналогии, что если на соответствующем уровне изоляции аномалия присутствовать не может - то реализация также не соответствует Стандарту? (-:
Стандарт:
The isolation level specifies the kind of phenomena that can occur during the execution of concurrent SQL-transactions
Надо заметить, я нигде в тексте не сказал, что Postgresql ведёт себя не согласно Стандарту. Я только сказал, что Mysql и SQLServer ведут себя согласно Стандарту, а в PostgreSQL этот уровень соответствует уровню Read Commited.
Точно такие же блокировки захватывает:
С таким же планом запроса
Да, если смотреть более обще) Этот момент как раз показан во втором пункте статьи
*бОльшей
Да, именно так и есть - к примеру, инвест фонды Кремниевой долины - главное, проработать свою идею так, чтобы она понравилась инвестору, а уж взлетит она или нет - это дело десятое. Сотни миллионов долларов в проекты, которые порой вообще ни доллара дохода не принесли. Ответвления по всему миру - и в России тоже были в виде Silicon Valley Insiders от венчурных инвесторов Yellow Door, к примеру.
Отсутствие неповторяющегося чтения не доказано - нет Delete операции
Ну, воображение он точно помогает развить))
Это же он сказал в Государе:
"ибо люди всегда дурны, пока их не принудит к добру необходимость" ? (:
@AlexeyK77Ну вообще же ребята неверно. Откуда только что берете? Во - первых, не "Phantom read", а "Phantom". Это уже потом выводится, что "Phantom" это "read"
Во - вторых, "NON-repeatable read" это про Update/Delete.
"Phantom" это "INSERT"
Все эти определения идут от Стандарта ISO/IEC 9075, согласно нему(стр84):
P2 (‘‘Non-repeatable read’’): SQL-transaction T1 reads a row. SQL-transaction T2 then modifies or deletes that row
P3 (‘‘Phantom’’): SQL-transaction T1 reads the set of rows N that satisfy some . SQL-transaction T2 then executes SQL-statements that generate one or more rows