tgoop.com/golang_digest/65
Create:
Last Update:
Last Update:
Defer your mutex Unlocks
https://www.ribice.ba/defer-mutex-unlocks/
Очень короткая статейка минут на 5 о том, почему нужно вызывать mutex.Unlock() именно в defer
У автора случилась классическая история: у них была функция, окруженная Mutex Lock / Unlock. Она не должна была паниковать, но внезапно делала это. Поэтому до Unlock дело не доходило и мьютекст оставался залоченным.
Наглядней всего проблему демонстрирует код:
defer func() {После фикса:
if err := recover(); err != nil {
fmt.Println("Recovered") // mutex.Unlock() missed!
}
}()
mutex.Lock()
functionCallThatPanics()
mutex.Unlock()
defer func() {————
if err := recover(); err != nil {
fmt.Println("Recovered")
}
}()
m.Lock()
defer m.Unlock() // will be called even after panic
functionCallThatPanics()
От себя добавлю: в большинстве случаев лучше использовать Unlock именно в defer. Да, это создает некоторый оверхед по производительности, зато спасает от описанных выше фэйлов. Если у вас нет необходимости тонкой оптимизации, то лучше не рисковать.
Кроме того, это довольно простой случай, а чаще бывает сложнее - когда между Lock / Unlock происходит несколько вызовов, и часть из них могут вернуть ошибку. В таком случае в 99.9% случаев нужно использовать именно defer, иначе вероятность багов многократно вырастает.
#article #english #mutex
BY Golang Дайджест
Share with your friend now:
tgoop.com/golang_digest/65