/ go Public
context: cancelCtx exclusive lock causes extreme contention #42564
FrozenDueToAge help wanted NeedsInvestigation
Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
What version of Go are you using (
Does this issue reproduce with the latest release?
What operating system and processor architecture are you using (
What did you do?
Passed a single context with cancellation to a bunch of goroutines.
These goroutines had a cold-path compute task, interlaced with calls to
context.Err()to detect cancellation.
The loop looks something like:
What did you expect to see?
A bit of a slowdown from the context check maybe?
What did you see instead?
Slightly over 50% of the CPU time was spent in
cancelContextstruct uses a
sync.Mutex, and due to extreme lock contention (64 CPU threads spamming it), this was triggering
lockSlow. From poking at pprof, it appears that about 86% of CPU time was spent in functions related to this lock acquire.
I was able to work around this by adding a counter and checking it less frequently. However, I do not think that this is an intended performance degradation path. Theoretically this could be made more efficient with
sync/atomic, although I think a
sync.RWMutexwould still be more than sufficient.
The text was updated successfully, but these errors were encountered: