You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
There is a common trick for reduction of contention on sync primitives. Unfortunately it
does not have a common name, but see mutexWaiterShift handling in sync/mutex.go for an
example. We can use it for async channels to reduce contention as well. Namely:
- add a waiterAwake flag to Hchan
- when a goroutine sends to async chan and there is a parked receiver, if
waiterAwake=false unpark it and set waiterAwake, otherwise do nothing
- if the woken receiver discovers empty queue, it resets waiterAwake before parking again
- if the woken receiver successfully dequeues from the queue, it does:
if queue empty || no parked receivers {
waiterAwake = false
} else {
unpark one parked receiver
// responsibility to manage waiterAwake and subsequent parked receivers
// transfers to that next recevier
}
This algorithm ensures that there is at most 1 excessive receiver loafs about producing
unnecessary contention. When this receivers goes away, it wakes up another receiver. And
so on.
The text was updated successfully, but these errors were encountered:
Under the 11506's scenario, the sender goroutine will also participate in receiving the value (or an-already-running goroutine), so who gets to run once the parked receiver gets unparked?
Let's say in your proposed workflow,
goroutine 1 sent.
goroutine 2 unparked.
Now I think 1 and 2 are both possible to get dequeue the value. At this moment, how schedule picks which to run?
The text was updated successfully, but these errors were encountered: