mirror of https://github.com/golang/go.git
runtime: release worldsema before Gosched in STW GC mode
After CL 182657 we no longer hold worldsema across the GC, we hold gcsema instead. However in STW GC mode we don't release worldsema before calling Gosched on the user goroutine (note that user goroutines are disabled during STW GC) so that user goroutine holds onto it. When the GC is done and the runtime inevitably wants to "stop the world" again (though there isn't much to stop) it'll sit there waiting for worldsema which won't be released until the aforementioned goroutine is scheduled, which it won't be until the GC is done! So, we have a deadlock. The fix is easy: just release worldsema before calling Gosched. Fixes #34736. Change-Id: Ia50db22ebed3176114e7e60a7edaf82f8535c1b4 Reviewed-on: https://go-review.googlesource.com/c/go/+/208379 Run-TryBot: Michael Knyszek <mknyszek@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Cherry Zhang <cherryyz@google.com>
This commit is contained in:
parent
1c5bd3459b
commit
05511a5c0a
|
|
@ -1368,6 +1368,13 @@ func gcStart(trigger gcTrigger) {
|
|||
work.pauseNS += now - work.pauseStart
|
||||
work.tMark = now
|
||||
})
|
||||
|
||||
// Release the world sema before Gosched() in STW mode
|
||||
// because we will need to reacquire it later but before
|
||||
// this goroutine becomes runnable again, and we could
|
||||
// self-deadlock otherwise.
|
||||
semrelease(&worldsema)
|
||||
|
||||
// In STW mode, we could block the instant systemstack
|
||||
// returns, so don't do anything important here. Make sure we
|
||||
// block rather than returning to user code.
|
||||
|
|
@ -1375,7 +1382,6 @@ func gcStart(trigger gcTrigger) {
|
|||
Gosched()
|
||||
}
|
||||
|
||||
semrelease(&worldsema)
|
||||
semrelease(&work.startSema)
|
||||
}
|
||||
|
||||
|
|
|
|||
Loading…
Reference in New Issue