Slava
если подробности будут не в личную - то почему бы и не запостить на всех =)
Daniil
Daniel
ну вот совсем другое дело :) а то "обращение"..
it is an official translate, ващета
Oleksandr
it is an official translate, ващета
да я не спорю, но я не на факультете компьютер сайнс учился, так что совковых учебников не застал. а то, что читал сам, естественно было на ангельском
Daniel
гугл вполне годную википедию выдает первой же ссылкой на этот запрос
Daniel
так что - не катет ваша гипотенуза
Oleksandr
ну так гугл и алгоритм reverse linked list выдаёт в первой ссылке. мы же про гипотетическое собеседование говорим
Anya
Помнится правила говорили что нужны ссылки и больше инфы а не просто собирание базы лидов по го
Anya
Простите великодушно, кину сюда ссылку, как красивое описание будет готово))
Daniil
Теоретический Вопрос по Mutex.
Допустим, у нас есть слайс типов, которе сами по себе структура.
MyType и sliceMyType.
В этом слайсе мы храним MyType, как они есть.
И вдруг я создаю слайс с указателями на этот тип из sliceMyType, называю его slicePointMyTypes, заполняю его указателями.
Потом я сделал Mutext на действия с slicePointMyTypes и циклом по указателю поле поле во всех MyType.
Вопрос будет ли применён Mutex на оригинальный sliceMyType? Хоть мы его и не используем, но по указателю мы идём к его данным.
Не знаю как проверить на практике, что блокируется, а что нет.
Нарисовал схемку.
(пжлст сильно не бейте)
Daniil
Daniel
есть подозрение, что вы не понимаете, как работают мутексы в go
Daniil
Верное :(
Мерль
Теоретический Вопрос по Mutex.
Допустим, у нас есть слайс типов, которе сами по себе структура.
MyType и sliceMyType.
В этом слайсе мы храним MyType, как они есть.
И вдруг я создаю слайс с указателями на этот тип из sliceMyType, называю его slicePointMyTypes, заполняю его указателями.
Потом я сделал Mutext на действия с slicePointMyTypes и циклом по указателю поле поле во всех MyType.
Вопрос будет ли применён Mutex на оригинальный sliceMyType? Хоть мы его и не используем, но по указателю мы идём к его данным.
Не знаю как проверить на практике, что блокируется, а что нет.
Нарисовал схемку.
(пжлст сильно не бейте)
Да, будет
https://gobyexample.com/mutexes
https://golang.org/pkg/sync/
Zver
Верное :(
Мютекс используется, для выполнения каких-то действий эксклюзивно. Если вы знаете, что к каким-то данным будет обращение из нескольких потоков, то все действия с этими данными оборачиваете в мютексы и все. Внутри одного потока мютексы не нужны.
Daniel
то, что горутина блокируется на попытке взять занятый мутекс - это побочный эффект
Daniel
полезный побочный эффект
Daniel
соответственно, если ваш код берет (лочит) мутекс - он этот эффект может использовать
Daniel
не берет - не может
Daniel
в отличие от явы, где мутекс распростряняется на synced блок кода, в го мутекс надо явным образом отпускать
Daniel
если вы забудете его отпустить - его никто больше не возьмет
Daniel
кстати, @kirilldanshin , это было бы полезно втащить в ваш goodlng
Daniel
как и реентерабельные мутексы
Daniil
А теперь вот так вот:
Две функции, которые меняют переменную.
Они могут вызваться одновременно (ну или во время исполнения одной из них) из параллельных горутин. Обе обёрнуты в mutex
ЧТо произойдёт? Одна гоурутина будет ждать пока выполнит действия первая над этой переменной? Или т.к. это разные функции, то они выполнятся одновременно?
Что синхронизирует mutex область памяти или действия одной функции?
Daniel
первая горутина вызывает Lock(), и он возвращается сразу
Daniel
вторая горутина вызывает Lock() - и он не возвращается, пока первая не вызовет Unlock()
Daniel
как только первая вызвала Unlock() - управление из Lock() второй горутины возвращается в нее
Daniel
так понятно?
Daniel
никаких других связей ни с переменными, ни с кодом у мутекса нет
Daniil
Всё теперь понял.
Я просто думал они ждут не освободили ли переменную.
Т.е. получается не важно что заблокировано, горутины будут просто ждать, пок кто-то не отпустит Mutex?
Daniel
именно
Daniel
и не кто-то, а тот, кто его взял
Daniel
впрочем - я не проверял!
Daniil
Эх.. в мечтах было красивее.
Daniel
ну - в go мутексы так себе
Daniel
поэтому большую часть того, что мы привыкли делать на мутексах, надо делать на каналах
Daniel
например, две функции
Daniil
Т.е. много Mutex очень вредно, как тогда ещё можно синхронизировать работу над одной областью пмяти?
Daniel
еще канал и еще одна горутина
Daniel
две функции пишут в канал, а третья из канала читает и монопольно переменную меняет
Daniil
А кналы не на Mutex реализованы?
Daniel
поэтому канало сыщественно медленнее мутексов
Slava
на mutex но там есть хитрости
Мерль
Т.е. много Mutex очень вредно, как тогда ещё можно синхронизировать работу над одной областью пмяти?
Если у вас целые типы uint64, то можно использовать атомарные операции, без блокировок
Daniel
но ctst строгие отцы говорят нам игнорировать это
Daniel
Они там вполне стандартные.
я в яве привык к реентерабельным мутексам, которые втоматически отпускаются по завершении блока. в go этого нет
Daniil
Не, у меня задумка над паралелльной работй с одним слайсом, кто-то может читать, 10 других гоурутин заходят написать или убрать в него что-то.
Мерль
Мне with в go не хватает :с
Daniel
Slava
@onokonem ты можешь сам такую функцию написать =)
Daniel
какую?
Kirill
Daniil
тогда изучите RWMutex
Да, это я уже делал, просто одним придётся ждать, пока другие пишут, вот я и хотел поделить на разные слайсы (когда был неверно одурманен мыслями про mutex)
Kirill
"напишите обращение односвязного списка"
чуть не испортил тебе вопрос для этого чята уточнением а-ля *кусок кода* ты это имел ввиду?. потом задумался. тут же ничего другого не придумаешь.
слаб я в русских терминах.
Daniel
Да, это я уже делал, просто одним придётся ждать, пока другие пишут, вот я и хотел поделить на разные слайсы (когда был неверно одурманен мыслями про mutex)
можно поделить, конечно же. будет структура с меньшей вероятностью блокировки
Daniel
ааааааа!
Daniel
взять лок может один, а отпустить другой
Daniel
аааа!!!111
Daniel
https://play.golang.org/p/oVZZsCBmQp
Daniel
даже вот так: https://play.golang.org/p/cVnVhL7gql
Daniel
понятно, почему мутексы нереентерабельные
Kirill
это одна из причин, по которой я не люблю mutex'ы
Daniel
я не знал
Daniel
я был наивен
Slava
а я не люблю циклы, там вообще ужасные вещи могут происходить =)
Daniil
А зачем кому-то отпускать мьютекс перед тем как его использовать?
Daniel
А зачем кому-то отпускать мьютекс перед тем как его использовать?
как раз строго противопоказано
Kirill
я их в начале года фиксить буду, но сначала я хочу сделать их максимально бесполезными.
Daniil
А если поменять архитектуру и хранить не в сайлсах, а БД сделать, по типу Redis, тогда все просто будут в очереди к БД?
Лучше или хуже, чем накидать mutex?
Мерль
А зачем кому-то отпускать мьютекс перед тем как его использовать?
Так делать нельзя, если разблокировать незаблокированный мьютекс, то программа упадёт
Daniil
А если поменять архитектуру и хранить не в сайлсах, а БД сделать, по типу Redis, тогда все просто будут в очереди к БД?
Лучше или хуже, чем накидать mutex?
Ну тащемто на соединение с базой тоже должен быть сьютекс)
Slava
плюс в самой базе будет мьютекс
Daniil
даже вот так: https://play.golang.org/p/cVnVhL7gql
Если навернуто поверх pthread_mutex - unlock может сделать или тот кто сделал lock или тред, ко орый владеет мьютексом. Емнип.
Slava
это как если бы не нравилась скорость работы автомобиля, поэтому мы взяли параход летающий