3 ms·
Because it came up recently for me (triggered a starvation bug), a caution for people expecting Go to randomize everything like this: Blocked channel reads and
by Groxx 2y ago
Because it came up recently for me (triggered a starvation bug), a caution for people expecting Go to randomize everything like this:
Blocked channel reads and writes are unblocked in FIFO order, not random. Mutexes are similar (afaict not quite identical, but the intent is the same).
Go randomizes a lot and I am thrilled they do that, and I knew about mutexes already, but the chan part was a surprise to me. It's reasonable and matches mutexes, so that's probably for the better, but still a bit oof.
- hombre_fatal 2y agoMeh, what if people rely on randomness. They should flip between random and ordered at random too.
- therein 2y agoYeah, gotta keep the programmer on his toes. He needs to embrace non-determinism, and second guess everything. In case Go developer switches to a different language, we don't want to build bad habits. Map key iteration should be non-deterministically deterministic.
- ithkuil 2y agoWell, every once in a while the random order will look like it's ordered
- akira2501 2y ago> Meh, what if people rely on randomness. Then they are creating fragile software. They're always one language version upgrade away from disaster.
- deleted 2y ago[deleted]
- hombre_fatal 2y agoYes, but that criticism already applies to the original iteration order before Go introduces a performance penalty by intentionally randomizing order on every iteration just so people can't rely on it.
- akira2501 2y ago> Blocked channel reads and writes are unblocked in FIFO order, not random This should be obvious since the buffer is optional. > but the chan part was a surprise to me With multiple receivers it is effectively random _which_ receiver gets the wakeup.
- Groxx 2y agoYeah, I don't mean buffered data. I mean blocked queueing operations. >With multiple receivers it is effectively random _which_ receiver gets the wakeup. That's why I brought it up: no it isn't. It's ordered. Intentionally. https://github.com/golang/go/issues/11506 https://github.com/golang/go/issues/11506 It's pretty easy to prove to yourself too, it only takes a couple dozen lines to write a test. I'm not confident it's guaranteed in all scenarios (mutexes are not, for example), but I've yet to see it do anything but perfect FIFO when not racing on starting both read and write simultaneously. --- A single select statement with multiple eligible channel operations is random, which is part of why I expected blocked channel operations themselves to be random. But nope.