goroutine/schedular starvation

[gopherbot]

by kbsriram:

http://play.golang.org/p/06bz6Td0Mg

Why does only writer1 get scheduled? (Or is the code itself required to account for
potential goroutine starvation?)

[PS: thanks to discussion on freenode/#go-nuts for isolating this specific example.
There are other biases present in an unbuffered channel, but none as interesting as the
previous one. eg: http://play.golang.org/p/g9pxx3R3BV]

[dvyukov]

Comment 1:

Does this affect any real programs?
I am inclined to mark this as #Unfortunate. The goroutines are actually scheduler in
perfect FIFO. It just happens so that when writer2/writer3 run, the chan is already
filled by writer1. Then consumer gets all messages, writer1 fills the chan,
writer2/writer3 are out of work, etc.

[gopherbot]

Comment 2 by kbsriram:

I'm a newcomer to Go, and can't speak for whether it affects real programs. Also as a
result, my advance apologies for conceptual misunderstandings (though I have been a
programmer for longer than I care to remember :-)
I'm wondering whether a Go programmer should code with the assumption that multiple
goroutines waiting to read or write on a channel can potentially starve?
For instance, taking this example from one of the google i/o presentations
http://talks.golang.org/2013/advconc.slide#6
Clearly it terminates in practice, but it appears to rely on the ability for the main()
routine to eventually get a chance to read from the "table" channel, since one of the
other player goroutines is always reading from that channel as well.
I'm wondering if I'm missing some basic assumption about interactions between the
scheduler, blocking calls and goroutines that lets this sort of situation work in
practice?
To crystallize my question even further[1]
http://pastebin.com/FgwrTid1
fails to terminate on my local go install (go version go1.1.1 darwin/386)
however, this one *does* terminate
http://pastebin.com/UQpZFs5D
with the only difference being changing the sleep in the "stopper" goroutine from Micro
to Milliseconds.
[1] I appreciate that select'ing on secondary control channel could be used to "stop"
the primality test. It's more about demonstrating seemingly minor interactions between
blocking calls and the scheduler do result in significant changes in the behavior of the
goroutines, rather than how to "fix" the example.
[2] I've placed the results from my local go install rather than from play.golang.org,
because it shows a different set of behaviors; and I'm not familiar with any additional
restrictions it may be employing.

[dvyukov]

Comment 3:

Thanks!
> I'm wondering whether a Go programmer should code with the assumption that multiple
goroutines waiting to read or write on a channel can potentially starve?
Definitely no. If it negatively affects real programs, then it's definitely a bug in Go
implementation.
This issue was never reported before.
For server type applications, goroutines routinely block on IO and are scheduled mostly
chaotically (in the good sense of this word in this context).
For HPC type applications, you usually don't care what exactly computation runs, you
need to do them all anyway. So this is fine to schedule one goroutine as long as it has
work to do, when the first goroutine finishes the goroutine will be scheduled and so on.
>[2] I've placed the results from my local go install rather than from play.golang.org,
because it shows a different set of behaviors; and I'm not familiar with any additional
restrictions it may be employing.
Yes, playground is somewhat special for security reasons.

Labels changed: added priority-later, removed priority-triage.

Status changed to Thinking.

[gopherbot]

Comment 4 by kbsriram:

Great, understood. Appreciate the clarifications Dmitry - thanks!

[adg]

Comment 5:

I don't think it's worth keeping this issue open unless we have a real program that
exhibits these issues.

Status changed to Unfortunate.