Scheduling and timer weirdness and goroutine starvation on Mac OS X

332 views
Skip to first unread message

Andreas Krennmair

unread,
Jun 4, 2013, 5:48:08 PM6/4/13
to golang-nuts
Hello,

Yesterday I wanted to test the fairness of the Go scheduler in situations with lots of small amounts of data pushed through channels.

So I devised this small test program: http://play.golang.org/p/ZyH7hfsP2q

And I compiled it with Go 1.1 (Darwin 64bit on OSX 10.8.3) and started it. Now, for how long would you think the program would run until it terminates? Roughly 20 seconds? Nope. On my machine, it never terminated. I even let it run for 2 hours during a meeting, all it would do is eat CPU time and return my computer into a little electric heater.

So, I started playing a bit around. dtruss wouldn't work because apparently it makes bsdthread_register() fail. So I thought that maybe setting GOMAXPROCS=2 or higher would change things because then the 3 goroutines (including main) would be scheduled between the OS threads. So, that's what I did, and suddenly the program worked perfectly, counted all the 1s and 2s, terminated after about 20 seconds, and even showed that the scheduling seems rather fair (i.e. roughly the same amount of 1s and 2s were received).

I showed this result to some of my work colleagues, and nobody could see any obvious problem in my code. Hmm. We then asked ourselves whether this had been a problem in previous versions, and so I recompiled the test program with Go 1.0.3. With GOMAXPROCS=1, the program terminated, but consistently showed that one character was received about twice as often as the other one. So the original problem that I had with Go 1.1 couldn't be reproduced, but scheduling doesn't seem exactly fair. With GOMAXPROCS=2, scheduling became fairer and roughly the same amount of both characters was received.

Bonus content:

I modified the program to make the channel buffered. With Go 1.0.3 and a buffered channel size of 1, the amount of 1s and 2s would be pretty much the same, both with GOMAXPROCS=1 and 2. When increasing the size of the buffered channel to 1000 (yes, one thousand), I suddenly had the effect that one of the sending goroutines was completely starved and didn't manage to put any of its characters into the channel. Weird.

With Go 1.1 and a buffered channel, I had exactly the same problems as with Go 1.1 and the unbuffered channel.

N.B.: I briefly tried this out on a 64-bit Linux, and wasn't able to reproduce any of the effects described above.

So all in all, this whole thing seems rather weird to me, and I can't recognize the root cause for it. dtruss didn't like me at all, so I lack the insight whether something's going wrong on the system call side. But my gut feeling tells me that things absolutely shouldn't be like that. Any ideas what the problem might be here?

Best regards,
Andreas Krennmair

mikey

unread,
Jun 4, 2013, 9:38:54 PM6/4/13
to golan...@googlegroups.com

I can't comment on your specific problem, but I have been playing around with profiling in Go v1.1 on OS X and something similar sounding is happening.


I added the following to the beginning of a program and ran the program for about 10 seconds:


f,profErr := os.Create("profileData.prof")

if profErr != nil {

� � log.Fatal(profErr)

}

pprof.StartCPUProfile(f)

defer pprof.StopCPUProfile()


I expected there to be roughly 1000 samples to be collected but instead there were only about 25.I suspect that the profiler is running in a separate goroutine and that it isn't being scheduled correctly.

--

You received this message because you are subscribed to the Google Groups "golang-nuts" group.

To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts...@googlegroups.com.

For more options, visit https://groups.google.com/groups/opt_out.


Dmitry Vyukov

unread,
Jun 5, 2013, 4:34:08 AM6/5/13
to Andreas Krennmair, golang-nuts
Please file the bug at http://golang.org/issue/new

Andreas Krennmair

unread,
Jun 5, 2013, 5:10:11 AM6/5/13
to Dmitry Vyukov, golang-nuts
Reply all
Reply to author
Forward
0 new messages