Help with WaitGroup...

In this code,, why does bar (is the following the correct word?) execute before foo?


bar runs first mainly because main() process is still running and was given instruction to execute bar() right after foo() delegation (or in actual term: forking). Remember that main() itself is still a process.

when a new process is forked, it will take some (edit: unpredictable amount of) times to setup before execution comparing to main() process which is an already running process.

1 Like

It does not necessarily need to.

In fact execution order of foo() and bar() in this case is not defined, and in theory could have been interleaved as well.

(On the playground though it will always produce this output, as the environment is prepared in a way that makes scheduling, or randomness in general reproducable)


Good one to bring up that important point. Thanks! :sweat_smile:

I ran your code in my local systems and they are always consistent: bar() is before foo(). However, do notice that in concurrency, they will never end beautifully like the one in the playground. Here is one of the run in my local system (after 20 runs):

OS               linux
ARCH             amd64
CPUs             8
Goroutines       1
bar: 0
bar: 1
bar: 2
bar: 3
bar: 4
bar: 5
bar: 6
bar: 7
bar: 8
bar: 9
CPUs             8
foo: 0
foo: 1
foo: 2
foo: 3
foo: 4
foo: 5
foo: 6
foo: 7
foo: 8
foo: 9
Goroutines       2

Keep in mind that concurrency is not parallelism. That is a totally different beast.

@Noobz, the start order is defined in the code specifically line 18 (delegate) then to line 19 (execute bar()). However, the way main and foo goroutines executes concurrently in a single cpu is not predictable.

1 Like

So to me it would appear that in the output, foo would come first.

In attempting to use the quote button , some how this reply came befor my reply to NobbZ


This confuses me. What exactly does this mean?

randomness in general reproducable

Are you saying that the execution is random? So that it was possible for foo to run before bar, or for bar to run before foo?

So this sounds like the execution is random.

Or does this…

mean something other than the execution is random.

Does somehow

go foo()

tell foo to run after bar?


go foo() doesn’t say must run after bar() but rather, starting another process to run foo(). That starting has its own meta-processes to initialize before it can run the actual foo(). That’s why foo() comes in later comparing to bar() which is an established process.

Also, keep in mind that by delegating process using goroutine does not guarantees it will start immediately. That’s why foo() somehow looks like it starts later yet I can’t tell how long it will start executing foo().

The execution is random as in there is no telling what (bar or foo) is running at one time on that single cpu so the output is chaotic. Notice the difference between the playground output and the one I quoted. The output are not consistent.

As for why, you can refer to this thread: Question on concurrent.

1 Like

This is an interesting phrase in itself, and when I searched for it on
Google, I got some interesting definitions.

Very interesting.


I think I’m good with this for now. You said something on another topic about marking something as solved? How do I do this, and if I do so, will I be able to come back and study it at a later date?

1 Like

You can review all the replied posts and look out for the most appropriate one. Then notice there is a checkbox. Select on it will mark that reply as the solution to your question.

You can actually bookmark your own question, either via browser bookmark OR the forum bookmark. go to the question and expands the option (3 dots). There is a bookmark symbol there. Click on it.

1 Like

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.