37:40 по мне не совсем корректное решение. Мы вычитаем значение только из 1 канала и пойдём дальше. В качестве решения можно запустить for range по joinChannels(), а в функции worker() после передачи значения в канал закрывать его и не получить deadlock.
Ну наконец то вышло видео, а то я не успел все посмотреть. Подача - отлично, объяснение - отлично, всё - отлично! Берем весла - гребем дальше! Только вперед!
жесткий диск в хлам не убъется, т.к. мы не пишем физически на винт - мы сбрасываем данные в кеш, который будет осью залит на винт физически тогда, когда придет его очередь на синхронизацию
@@Gusto20000 тогда мы упремся в ио и будем ждать, пока в очереди на запись не появится место да и вобоще, я не уверен, что где-то кто-то еще использует блины в хайлоаде
Немного осмыслив ваш кэш могу сделать следующие выводы. Очень удручает что GOшники начали писать как JSкриптеры. Мьютексы не нужно использовать, если можно использовать атомик, не надо использовать атомик, если можно его не использовать. В вашем случае не нужно использовать ни первое, ни второе. Кэш вашего типа подразумевает получение неактуального значения. У вас один писатель и множество читателей. Атомик это просто инструкция процессора с LOCK префиксом, которая запирает шину памяти на время её выполнения. Поскольку в вашей программе используется всего одна переменная типа int, запись этого числа сама по себе атомарна, нельзя записать полинта. Если же у вас сложная структура, то нужно писать в буферную структуру, а затем менять указатели. И в этом случае у вас так же будут консистентные данные.
int в го весит 64 байта по умолчанию,поэтому если архитектура процессора x32,то запись в инт будет неатомарна, на счёт того,что атомик лишний - не уверен. Что если ядра,на которых запустились горутины закешировали интовое значение,даже если оно будет обновлено в другой горутине(которая фоновая раз в секунду обновляет), то они могут видеть старое значение, атомики же расставляют барьеры на чтение. Благодаря этому будет прочитано актуальное на данный момент значение Также атомик должен гарантировать атомарную запись в тип данных,который весит больше чем архитектура процессора
@@kafychannel Освежите информацию по типам. int и uint в большинстве случаев зависят от архитектуры. В 32битных системах как правило они имеют размерность 4 байта(32бита). 64 байта не занимает не один простой тип. Возможно спутали с размером кэш линии или биты с байтами путаете. Для того что бы запретить переменную кэшировать в регистре используются волатильные переменные. По поводу актуальности значения, если вы его кэшируете, значит в 99.9...9% Вам плевать на актуальность значения.
@@bigtown2012 соглашусь,что волатильные переменные решают проблему с актуальностью значения, но в голэнге у нас нет volatile переменных,потому что в этом ЯПе не поощряется шарить память с помощью глобальных полей,напротив нужно использовать акторную модель коммуникаци: передачу данных из одного актора другого посредством общей шины, но если мы хотим делать глобальное поле писать в него и читать из него,то нужно позаботиться о видимости значения в других потоках,в гошке для этого есть атомик,который решает не только проблему атомарного обновления,но и видимости
@@kafychannel Го мой второй ЯП на котором я программирую. И это происходит раз от разу. Но насколько я помню модуль volatile есть и делает он вроде как тоже самое. В целом согласен, все зависит от задачи. Кэш это как правило про хайлоад и тут как правило скорость самый важный аспект. Хотя конечно все зависит от задачи. Если актуальность значения важна, то атомик, если нет я бы начал с обычной переменной. Про общую шину не понял. Если про канал, то это память в куче с мьютексом. Хотя и сложилось практика везде их пихать, но это не хорошая идея.
37:40 по мне не совсем корректное решение. Мы вычитаем значение только из 1 канала и пойдём дальше. В качестве решения можно запустить for range по joinChannels(), а в функции worker() после передачи значения в канал закрывать его и не получить deadlock.
09:09 к сути дела для тех, кто уже в курсе про менторскую программу и крутой онлайн-редактор кода для собесов 😉
Мне нравится фраза, ну мы "не хотим лочится". И поэтому мы используем кучу каналов и груп внутри которых мьютексы.)
21:50 так ведь с локом теряется конкурентность, нет?
Ну наконец то вышло видео, а то я не успел все посмотреть. Подача - отлично, объяснение - отлично, всё - отлично! Берем весла - гребем дальше! Только вперед!
Интересный у вас кеш… пользователи спят, эндпоинт никто не дергает, а у вас каждую секунду выполняется нагрев атмосферы 😂
32:00 это называется Fan-In pattern
жесткий диск в хлам не убъется, т.к. мы не пишем физически на винт - мы сбрасываем данные в кеш, который будет осью залит на винт физически тогда, когда придет его очередь на синхронизацию
А кеш, конечно же, бесконечен
@@Gusto20000 тогда мы упремся в ио и будем ждать, пока в очереди на запись не появится место
да и вобоще, я не уверен, что где-то кто-то еще использует блины в хайлоаде
Немного осмыслив ваш кэш могу сделать следующие выводы. Очень удручает что GOшники начали писать как JSкриптеры. Мьютексы не нужно использовать, если можно использовать атомик, не надо использовать атомик, если можно его не использовать. В вашем случае не нужно использовать ни первое, ни второе. Кэш вашего типа подразумевает получение неактуального значения. У вас один писатель и множество читателей. Атомик это просто инструкция процессора с LOCK префиксом, которая запирает шину памяти на время её выполнения. Поскольку в вашей программе используется всего одна переменная типа int, запись этого числа сама по себе атомарна, нельзя записать полинта. Если же у вас сложная структура, то нужно писать в буферную структуру, а затем менять указатели. И в этом случае у вас так же будут консистентные данные.
int в го весит 64 байта по умолчанию,поэтому если архитектура процессора x32,то запись в инт будет неатомарна, на счёт того,что атомик лишний - не уверен. Что если ядра,на которых запустились горутины закешировали интовое значение,даже если оно будет обновлено в другой горутине(которая фоновая раз в секунду обновляет), то они могут видеть старое значение, атомики же расставляют барьеры на чтение. Благодаря этому будет прочитано актуальное на данный момент значение
Также атомик должен гарантировать атомарную запись в тип данных,который весит больше чем архитектура процессора
@@kafychannel Освежите информацию по типам. int и uint в большинстве случаев зависят от архитектуры. В 32битных системах как правило они имеют размерность 4 байта(32бита). 64 байта не занимает не один простой тип. Возможно спутали с размером кэш линии или биты с байтами путаете. Для того что бы запретить переменную кэшировать в регистре используются волатильные переменные. По поводу актуальности значения, если вы его кэшируете, значит в 99.9...9% Вам плевать на актуальность значения.
@@bigtown2012 соглашусь,что волатильные переменные решают проблему с актуальностью значения, но в голэнге у нас нет volatile переменных,потому что в этом ЯПе не поощряется шарить память с помощью глобальных полей,напротив нужно использовать акторную модель коммуникаци: передачу данных из одного актора другого посредством общей шины, но если мы хотим делать глобальное поле писать в него и читать из него,то нужно позаботиться о видимости значения в других потоках,в гошке для этого есть атомик,который решает не только проблему атомарного обновления,но и видимости
@@kafychannel Го мой второй ЯП на котором я программирую. И это происходит раз от разу. Но насколько я помню модуль volatile есть и делает он вроде как тоже самое. В целом согласен, все зависит от задачи. Кэш это как правило про хайлоад и тут как правило скорость самый важный аспект. Хотя конечно все зависит от задачи. Если актуальность значения важна, то атомик, если нет я бы начал с обычной переменной. Про общую шину не понял. Если про канал, то это память в куче с мьютексом. Хотя и сложилось практика везде их пихать, но это не хорошая идея.
И это, пореже пользуйте копайлотом, а то так и будете такие кэши писать😉
зачем же так сложно про мьютекс?) Есть 2 состояния: locked = 1, unlocked = 2. Лок через compareAndSwap, анлок через атомик сет. Фсьо
Лучше про зарплаты расскажите, для мотивации апать скиллы, так сказать :)