runtime: use rwmutex for execLock #20738
Labels
Milestone
Comments
|
Broken link: CL 43713 |
|
CL https://golang.org/cl/47072 mentions this issue. |
|
CL https://golang.org/cl/47071 mentions this issue. |
gopherbot
pushed a commit
that referenced
this issue
Jun 28, 2017
Currently runtime.rwmutex is written to block the calling goroutine rather than the calling thread. However, rwmutex was intended to be used in the scheduler, which means it needs to be a thread-level synchronization primitive. Hence, this modifies rwmutex to synchronize threads instead of goroutines. This has the consequence of making it write-barrier-free, which is also important for using it in the scheduler. The implementation makes three changes: it replaces the "w" semaphore with a mutex, since this was all it was being used for anyway; it replaces "writerSem" with a single pending M that parks on its note; and it replaces "readerSem" with a list of Ms that park on their notes plus a pass count that together emulate a counting semaphore. I model-checked the safety and liveness of this implementation through >1 billion schedules. For #20738. Change-Id: I3cf5a18c266a96a3f38165083812803510217787 Reviewed-on: https://go-review.googlesource.com/47071 Run-TryBot: Austin Clements <austin@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
CL 43713 introduces a mutex around thread creation. We wanted to use rwmutex to avoid serializing thread creation, but rwmutex depends on semaphores, which depend on sudogs, which require allocation and write barriers, so we can't use them from
runtime.newm.We should try to figure out a way to fix this, possibly by rewriting rwmutex to not depend on semaphores.
/cc @ianlancetaylor @chipaca
The text was updated successfully, but these errors were encountered: