I don't think the author claimed this outputs in "round-robin scheduling". The lockstep here means both Ann and Joe outputting 0, then both outputting 1, ..., i.e. no one can output 1 before both have outputted 0. In particular, this is in contrast of the example a couple of slides before, where Joe can output 3, 4, 5 before Ann outputs 3 ( https://www.youtube.com/watch?v=f6kdp27TYZs&t=1095s ). I think this works as intended.

cc @robpike in case there is anything to clarify. Thanks.

Working as intended. No claim made for lockstep.

@cherrymui

• Thanks for fixing the issue’s title.

• You are correct, Rob never uttered "round-robin scheduling" during his presentation. I apologize for including this phrase in the initial post.

• I believe we agree that Rob intended the messaging in sequenceboring.go to execute in a lockstep synchronous/sequenced way. This is exactly what Rob said by the link provided in the initial post:

  "So when we run it now, you can see they're back in lockstep, because even though the timing is random, the sequencing here, with message 1 wait and message 2 wait, means that the..."

  Moreover, Rob concisely states when he begins the set of slides titled: “Restoring sequencing” his intention: “We wanted to have them be totally lockstep and synchronous.”

• I’m confident that the intended “sequence” behavior should strictly alternate between “Joe: N” and “Ann: N:” or vice versa due to the context of Rob’s statements. He titled the slides that explain the code in sequenceboring.go as “Restoring sequencing”. This phrase refers back to the discussion of generator2boring.go and focuses on its code segment. Rob describes the resultant message ordering as derived from: “the two guys are taking turns, not only in printing the values out but also in executing them”.

  In fact, due to the explicit Happens Before encoding of generator2boring.go Joe’s messages will always precede Ann’s which isn’t the case in sequenceboring.go.

• Although Rob posted “Working as intended.” to this thread, I believe he reviewed the link you provided which referenced the slides titled “Multiplexing”. The code discussed by the “Multiplexing” slides do not enforce lockstep behavior.

• Finally, I’m not the first individual to experience the reported anomaly in sequenceboring.go. I thought if others had encountered it, the issue might be more thoroughly reviewed instead of being immediately closed. I checked golang-nuts for an existing thread and found this mention by Tony Worm.