-4

This particular Go code uses a channel to synchronise goroutines.

// We can use channels to synchronize execution
// across goroutines. Here's an example of using a
// blocking receive to wait for a goroutine to finish.

package main

import "fmt"
import "time"

// This is the function we'll run in a goroutine. The
// `done` channel will be used to notify another
// goroutine that this function's work is done.
func worker(done chan bool) {
   fmt.Print("working...")
   time.Sleep(time.Second)
   fmt.Println("done")

   // Send a value to notify that we're done.
   done <- true
}

func main() {

   // Start a worker goroutine, giving it the channel to
   // notify on.
   done := make(chan bool, 1)
   go worker(done)

   // Block until we receive a notification from the
   // worker on the channel.
   <-done
 }

What is the need to synchronize goroutines? Isn't the idea that we will run goroutines in an interleaved way. Why would we want to introduce synchronization between two or more go routines? Is it for callbacks?

Thanks

Mojtaba Ahmadi
  • 1,044
  • 19
  • 38
amrx
  • 673
  • 1
  • 9
  • 23
  • Sometime two independent things need to coordinate. E.g. Stop doing things. – Volker Sep 16 '18 at 07:58
  • 2
    `Isn't the idea that we will run goroutines in an interleaved way.`. no. They run in parallel. –  Sep 16 '18 at 13:16
  • @mh-cbon: No, they run _concurrently_. They may or may not run in parallel, depending on your hardware and configuration. Required reading/watching: [Concurrency is not parallelism](https://blog.golang.org/concurrency-is-not-parallelism). – Jonathan Hall May 20 '19 at 12:00
  • @Flimzy, regarding the runtime internal, i totally agree with you. Would you agree to say that from higher point of view, the worst case scenario applies during the programming of this language, thus the programmer must assume that read/write operations will occur in parallel, and that synchronization failures must be avoided. In that regards saying it is parallel is kind of good enough to give the right understanding to the programmer ? –  May 20 '19 at 12:12
  • The programmer must assume that read/write operations occur concurrently. This is true regardless of parallelism. – Jonathan Hall May 20 '19 at 12:14
  • 1
    Saying "parallel" is different than saying "concurrent." Don't confuse the two. Don't teach others they are the same. :) – Jonathan Hall May 20 '19 at 12:16

2 Answers2

4

Concurrency doesn't happen in a vacuum. Coordination of the goroutines you start may be required for numerous reasons. In this case, there is one primary one (beyond the example, which is contrived as a demonstration):

  • The Go runtime will quit in the event the end of the main method is reached. At that point, the running program including all other goroutines will be terminated. The coordination here ensures the child goroutine has quiesced before the program is allowed to exit.

    I wrote about an example of this yesterday: https://stackoverflow.com/a/52347990/1113760.

You might imagine many other reasons which require coordination between concurrent work (this list is not specific to Go and is non-exhaustive):

  • The goroutines operate on a shared memory region, so require coordination in the form of mutual exclusion to ensure only one routine accesses the critical section at a time.

  • Your continued processing may depend on the output of multiple goroutines, so you wait for consensus before proceeding.

  • Your program may provide a service, and you want to ensure any in-flight requests (processed in separated goroutines) have completed and drained before you shutdown.

This question goes beyond Go to consider the computer science difficulties associated with concurrent execution, and the instances in which it is useful, so the literature will have further detail and examples.

Cosmic Ossifrage
  • 4,977
  • 29
  • 30
0

If processes can be run independently then things are pretty straight forward. We can run each process in a core and things will be easy. Issues comes when processes are dependent (ie process A dependent on process B).

Classical way to achieve this is by sharing a common memory and locking it such that only a process can access it at a given time. Go channel follows a different approach, you can read more about it here

Prabesh P
  • 150
  • 4