On Monday, March 26, 2018 at 4:09:24 PM UTC-4, Marvin Renich wrote: > > It seems that you understand why you are seeing the behavior you > reported, but you are questioning whether the spec either does or should > guarantee that reading from a channel with a goroutine waiting to send > on that channel will fill the buffer as an atomic part of the read. > > As others have said, the spec does not guarantee this. I would like to > add that I believe it shouldn't. Suppose goroutine A is currently > blocked waiting to send on a channel. Now goroutine B reads from that > channel. If the refill of the channel must happen atomically with the > read from that channel, now goroutine B must be put in a blocked state > waiting for goroutine A to finish its send. This contradicts the spec > at [1] which states > > ...communication succeeds without blocking if the buffer is not full > (sends) or not empty (receives). > > If you think about how this is likely to be implemented (including > considerations for GOMAXPROC and multicore vs single core systems), you > should realize that, while it would be possible to implement > atomic-refill, it would give no (or very little) benefit and might have > undesirable performance effects. > > As an aside, I think the reason Jake is seeing 100 lines of output and > you only see 1 is likely to be the difference between GOMAXPROC=1 and > greater than 1. If GOMAXPROC=1, the scheduler may force a running > goroutine to yield after receiving, but before returning from the > receive operation. In other words, the receive happens without > blocking, but the scheduler thinks that is a convenient point for giving > another goroutine an opportunity to run. >
No, I tried both GOMAXPROC=1 and GOMAXPROC=4. Same results. It is strange that I just tried it again, now there will be always 100 lines outputted, for both GOMAXPROC=1 and GOMAXPROC=4, for both v1.10 and v1.10.1. Quite strange. > > ...Marvin > > [1] https://golang.org/ref/spec#Channel_types -- 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+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.