Would you use this code sample to explain parallel execution in Go?

Getting Help
1

I think this could sample is a little bit confusing it should explain parallel code execution in Go:

https://play.golang.org/p/2g-Y3Y-FkZ

What do you think?

2

Don’t the two Goroutines run concurrent like in this example?

https://golang.org/pkg/sync/#example_WaitGroup

3

I’d say that parallel execution requires concurrent execution. Both goroutines are executed concurrent but not necessarily parallel. If the machine happens to only have one CPU or the runtime is capabale of using only one of the existing CPUs, execution is concurrent but not parallel. If tow CPUs are used for the two concurrent goroutines, execution can be parallel.

4

I just think if you want to explain parallel execution in Go thats a weird example, I took it from this German article wich is in my view not doing a favor for any Go beginner:

https://www.informatik-aktuell.de/entwicklung/programmiersprachen/go-parallel.html

I mean I’m not expert and just a hobby programmer but I wish there would be better learning materials and articles in German soon.

5

I still don’t quite your concrete criticism of this article. I’ve not worked through so I can not tell if it is good or bad. What do you think is weird about it and especially this example?

6

I the article the author says for example https://play.golang.org/p/2g-Y3Y-FkZ is executed explicity parallel if the Hardware allows it…

As far as I know Goroutines run on logical processors which are sheduled by the Go runtime at execution and the 2nd Goroutine will run on a different logical processor and thread if possible…

The article assumes that the programmer will get direct access to the hardware processors and directly change how Go executes the Goroutines…

I think that is wrong and not a good example

7

As far as I remember my lessons about parallelism and concurrency, the difference is not about logical processors, but about access to shared resources.

If two tasks can work independently from shared resources, then they are run in parallel, if though they share ressources and “fight” about them (or better have synchronized access) then they are concurrent. Synchronisation/shared access that is necessary to talk the result of a parallel computation back to a “supervisor” or “collector” is often still accepted for parallel tasks.

1 Like
8

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