“Ранее в Go для разрешения коллизий в хеш-таблицах использовался метод цепочек, при котором каждый бакет содержал указатель на связанный список элементов с одинаковым хеш-значением.» - ранее это насколько ранее? Мне вот это предложение не давало покоя. Насколько я помню, с go 1.8 в хеш - таблицах метод цепочек, предполагающий списки, уже не используется. Все хранится в одном большом массиве. И действительно:
Начиная с Go 1.8, реализация map в Go перешла с метода цепочек (связные списки в бакетах) на комбинацию открытой адресации и "bucket-ов"
А сколько по времени заявка рассматривается? Вчера подал заявку и пока никакого ответа. И да, пришлось на получение рекламных материалов согласиться, теперь заспамите?)
Покрасить все корневые объекты (стек и глобальные переменные) в серый.
Выбрать серый объект из набора серых объектов и пометить его как чёрный. (Из какого набора серых объектов? Мы же только что ВСЕ объекты покрасили в серый. Т.е. выбрать рандомно объект?)
Все объекты, на которые указывает чёрный объект, пометить серым. Это гарантирует, что сам объект и объекты, на которые он ссылается, не будут выброшены в мусор. (Так, мы покрасили ОДИН объект из ВСЕХ черным. Дальше мы все объекты, на которые указывает этот черный объект, помечаем серым. То есть на этом шаге мы не делаем НИЧЕГО)
Если в графе остались серые объекты, вернуться к шагу 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;
Прямо сборник типовых задач на собес по go. «Заучите их наизусть и куда - нибудь точно пройдете»
“Ранее в Go для разрешения коллизий в хеш-таблицах использовался метод цепочек, при котором каждый бакет содержал указатель на связанный список элементов с одинаковым хеш-значением.» - ранее это насколько ранее? Мне вот это предложение не давало покоя. Насколько я помню, с go 1.8 в хеш - таблицах метод цепочек, предполагающий списки, уже не используется. Все хранится в одном большом массиве. И действительно:
Как в старом советском анекдоте - "Если не можешь/не берут работать - учи. Если и учить не можешь - руководи"
А сколько по времени заявка рассматривается? Вчера подал заявку и пока никакого ответа. И да, пришлось на получение рекламных материалов согласиться, теперь заспамите?)
Наконец - то ВК перейдет с их кастомного PHP на Go. Давно пора!
И зарплату получал)
Хорошо, что картинками пояснено, было бы решительно ничего не понятно
Рассмотрим алгоритм логически, по шагам:
Покрасить все корневые объекты (стек и глобальные переменные) в серый.
Выбрать серый объект из набора серых объектов и пометить его как чёрный.
(Из какого набора серых объектов? Мы же только что ВСЕ объекты покрасили в серый. Т.е. выбрать рандомно объект?)
Все объекты, на которые указывает чёрный объект, пометить серым. Это гарантирует, что сам объект и объекты, на которые он ссылается, не будут выброшены в мусор.
(Так, мы покрасили ОДИН объект из ВСЕХ черным. Дальше мы все объекты, на которые указывает этот черный объект, помечаем серым. То есть на этом шаге мы не делаем НИЧЕГО)
Если в графе остались серые объекты, вернуться к шагу 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.
Точно такие же блокировки захватывает:
С таким же планом запроса