Разбор задач с собеседования по Go

Рет қаралды 3,236

2 ай бұрын

В этом видео Денис Максимов, старший разрабочтик и ментор в Навыках, разобрал задачи с собеседовний по Go
Запишись на мок-интервью или менторство в нашем боте, чтобы апнуть грейд и комплексно подготовиться к трудоустройству: t.me/skills_mentee_bot?start=...
Сайт Навыков: x.h.careers/skills/main?...
Чат Навыков в Телеграмме: t.me/naviky_chat
Сервис развития карьеры Эйч: h.careers/?...
Стань ментором в Навыках: docs.google.com/forms/d/e/1FA...

Пікірлер: 13

@nikolaykozlov4888 2 ай бұрын

Ну наконец то вышло видео, а то я не успел все посмотреть. Подача - отлично, объяснение - отлично, всё - отлично! Берем весла - гребем дальше! Только вперед!

@bigtown2012 Ай бұрын

Мне нравится фраза, ну мы "не хотим лочится". И поэтому мы используем кучу каналов и груп внутри которых мьютексы.)

@alexsunstrider638 2 ай бұрын

09:09 к сути дела для тех, кто уже в курсе про менторскую программу и крутой онлайн-редактор кода для собесов 😉

@gerojstalnoj9708 Ай бұрын

37:40 по мне не совсем корректное решение. Мы вычитаем значение только из 1 канала и пойдём дальше. В качестве решения можно запустить for range по joinChannels(), а в функции worker() после передачи значения в канал закрывать его и не получить deadlock.

@gregory._ 13 күн бұрын

21:50 так ведь с локом теряется конкурентность, нет?

@bigtown2012 Ай бұрын

И это, пореже пользуйте копайлотом, а то так и будете такие кэши писать😉

@devracoon 2 ай бұрын

Лучше про зарплаты расскажите, для мотивации апать скиллы, так сказать :)

@bigtown2012 Ай бұрын

Немного осмыслив ваш кэш могу сделать следующие выводы. Очень удручает что GOшники начали писать как JSкриптеры. Мьютексы не нужно использовать, если можно использовать атомик, не надо использовать атомик, если можно его не использовать. В вашем случае не нужно использовать ни первое, ни второе. Кэш вашего типа подразумевает получение неактуального значения. У вас один писатель и множество читателей. Атомик это просто инструкция процессора с LOCK префиксом, которая запирает шину памяти на время её выполнения. Поскольку в вашей программе используется всего одна переменная типа int, запись этого числа сама по себе атомарна, нельзя записать полинта. Если же у вас сложная структура, то нужно писать в буферную структуру, а затем менять указатели. И в этом случае у вас так же будут консистентные данные.

@kafychannel Ай бұрын

int в го весит 64 байта по умолчанию,поэтому если архитектура процессора x32,то запись в инт будет неатомарна, на счёт того,что атомик лишний - не уверен. Что если ядра,на которых запустились горутины закешировали интовое значение,даже если оно будет обновлено в другой горутине(которая фоновая раз в секунду обновляет), то они могут видеть старое значение, атомики же расставляют барьеры на чтение. Благодаря этому будет прочитано актуальное на данный момент значение Также атомик должен гарантировать атомарную запись в тип данных,который весит больше чем архитектура процессора

@bigtown2012 Ай бұрын

@@kafychannel Освежите информацию по типам. int и uint в большинстве случаев зависят от архитектуры. В 32битных системах как правило они имеют размерность 4 байта(32бита). 64 байта не занимает не один простой тип. Возможно спутали с размером кэш линии или биты с байтами путаете. Для того что бы запретить переменную кэшировать в регистре используются волатильные переменные. По поводу актуальности значения, если вы его кэшируете, значит в 99.9...9% Вам плевать на актуальность значения.

@kafychannel Ай бұрын

@@bigtown2012 соглашусь,что волатильные переменные решают проблему с актуальностью значения, но в голэнге у нас нет volatile переменных,потому что в этом ЯПе не поощряется шарить память с помощью глобальных полей,напротив нужно использовать акторную модель коммуникаци: передачу данных из одного актора другого посредством общей шины, но если мы хотим делать глобальное поле писать в него и читать из него,то нужно позаботиться о видимости значения в других потоках,в гошке для этого есть атомик,который решает не только проблему атомарного обновления,но и видимости

@bigtown2012 Ай бұрын

@@kafychannel Го мой второй ЯП на котором я программирую. И это происходит раз от разу. Но насколько я помню модуль volatile есть и делает он вроде как тоже самое. В целом согласен, все зависит от задачи. Кэш это как правило про хайлоад и тут как правило скорость самый важный аспект. Хотя конечно все зависит от задачи. Если актуальность значения важна, то атомик, если нет я бы начал с обычной переменной. Про общую шину не понял. Если про канал, то это память в куче с мьютексом. Хотя и сложилось практика везде их пихать, но это не хорошая идея.