Makes sense. Thanks very much. Simpler than a double waitgroup, same overall effect.
I may have a weird use case, but maybe this might be worth adding to the examples. — P > On Jan 16, 2021, at 6:14 PM, Robert Engels <reng...@ix.netcom.com> wrote: > > WaitGroups are deterministic in that sense. Whether they are all released at > once (there is no such thing as “at once” in practice) you have a race. True. Badly expressed on my part. I’d assumed the goroutine scheduler held them all up until all had seen the zeroing, so my ‘at once’ meant they had all seen the zero arrival, and then ran when the scheduler revived them. Scheduler thing, not clock thing. > > You can restructure this to avoid the race. You should Add() to to the stage > 1 and 2 wait groups after the Wait() returns and before you Wait() on the > stage 2. > >> On Jan 16, 2021, at 6:05 PM, Pete Wilson <peter.wil...@bsc.es> wrote: >> >> WARNING / LEGAL TEXT: This message is intended only for the use of the individual or entity to which it is addressed and may contain information which is privileged, confidential, proprietary, or exempt from disclosure under applicable law. If you are not the intended recipient or the person responsible for delivering the message to the intended recipient, you are strictly prohibited from disclosing, distributing, copying, or in any way using this message. If you have received this communication in error, please notify the sender and destroy and delete any copies you may have received. http://www.bsc.es/disclaimer http://bsc.es/disclaimer -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/C0E0121B-2D29-4F74-AC09-20651CB7D4C7%40bsc.es.
