они созданы исключительно для решения проблем синхронизации. Вдруг там та уровне hardware выполняются те же операции?
Ну проблемы синхронизации можно решать 1. через каналы 2. sync.Mutex, sync.WaitGroup 3. атомики Можно выбирать более производительный и читабельный вариант PS. Атомики только для атомарных операций
Я конечно не эксперт, но кажется первые построены на вторых, а вторые на третьих. А 3-е собственно реализованы на уровне железа. Как одна атомарная команда, которая выполняет несколько операций. 🤔 Или я что-то путаю?
Получается "ускорение" операции достигается только за счет того, что не тратится время на считывание нескольких команд?
можно еще делать монопольные блокировки без мьютексов😅 sema = make(chan struct{}, 1) ... sema <- struct{} balance++ <-sema
Так канал это же структура с мьютексом внутри.
почему кстати для большого кол-ва горутин каналы лучше чем мьютексы?
Я не знаю. Но вот тут: https://golang.org/src/runtime/chan.go явно мьютекс. Я ж говорю я не эксперт.
из-за паттерна доступа к данным + влияние GC на содержимое в канале (точнее отсутствие влияния)
Каналы более читаемый и классический вариант и рекомендуемый насколько я понимаю
все зависит от числа горутин одновременно работающих с примитивом синхронизации
было же исследование про число ошибок использования mutex vs channel и на каналах люди делают ошибки чаще.
о, вкупе с каким-то ограничением (например пул соединений) это эпический источник багов, все три драйвера для postgres мне известных когда-то налетали на такое
можно еще их смешать с sync.Cond, который требует Locker и будет праздник дедлоков )
Обсуждают сегодня