f5439ddc54
The deadlock was caused in transfermap.go by calling mu.RLock() in one
function then calling it again in a sub function. Normally this is
fine, however this leaves a window where mu.Lock() can be called. When
mu.Lock() is called it doesn't allow the second mu.RLock() and
deadlocks.
Thead 1 Thread 2
String():mu.RLock()
del():mu.Lock()
sortedSlice():mu.RLock() - DEADLOCK
Lesson learnt: don't try using locks recursively ever!
This patch fixes the problem by removing the second mu.RLock(). This
was done by factoring the code that was calling it into the
transfermap.go file so all the locking can be seen at once which was
ultimately the cause of the problem - the code which used the locks
was too far away from the rest of the code using the lock.
This problem was introduced in:
|
||
|---|---|---|
| .. | ||
| accounting.go | ||
| accounting_other.go | ||
| accounting_test.go | ||
| accounting_unix.go | ||
| inprogress.go | ||
| prometheus.go | ||
| stats.go | ||
| stats_groups.go | ||
| stats_groups_test.go | ||
| stats_test.go | ||
| token_bucket.go | ||
| token_bucket_test.go | ||
| transfer.go | ||
| transfermap.go | ||