Concurrency

One of Go's strength is its ability to perform concurrently (not parallelism). To go concurrent executions, we use the keywords: go for initiate the goroutine and channel for passing values between each processes.

Design Models

Multi-processing has various design models to work with. Among the known models are:

• Naive Monitoring / Sentinel Looping
• Cooperative Locking / Cooperative Threading / Non-Preemptive Threading
• Preemptive Threading
• Atomic Update Notification

In practical design, one can use multiple models depending on stack location and its deployment. The details for each models are beyond this page.

Long story short

• For Go, goroutine itself is using cooperative threading.
• When you initiate a new thread using go, it creates a new thread but does not guarantee its starting timing.
• Go also facilitates atomic update notification using channel for inter-process communications
  • Encourages a non-interrupt multiple process executions for better usage of CPU

In this page, we will look into how to initiate a thread and contact switching between them.

Basic Multi-threading - Single Receiver - Single Sender

The very basic for multi-threading is:

• 1 main process -> delegate process to another
• 1 way communications back to main process for signalling done
  • Otherwise, main will exit and terminate the program

Hence, the example would be:

package main

import (

        "fmt"

)

func task(ch chan string) {

        ch <- "Hello World"

        close(ch)

}

func main() {

        ch := make(chan string)

        go task(ch)

        fmt.Printf("doing something else\n")

        s := <-ch

        fmt.Printf("%v\n", s)

}

// Output:

// doing something else

// Hello World

Here is the phenomenons:

1. the main() creates a single channel for delegate to communicate back to itself.
   • ch := make(chan string)
2. the main() then proceed to delegate an execution into the thread, called task(...) using go keyword.
   • go task(ch)
3. the task(...) is executed in a separated thread.
   • func task(ch chan string)
4. the main() proceed to do something else immediately after the delegation.
   • fmt.Printf("doing something else\n")
5. before ending the program, the main() needs to wait for the delegate to signal its ends. the main() waits for the return signal.
   • s := <-ch
6. the task(...) completed its work and send the result back to main() via the channel.
   • ch <- "Hello World"
7. the task(...) closes the channel since there is nothing left to send.
   • close(ch)
8. the main() receives the input from the channel and save it into variable s.
   • s := <-ch
9. the main() continues the remaining work and exit the program maturely.
   • fmt.Printf("%v\n", s)

Some important points to remember:

• A channel is a one way, atomic notification communicator between multiple processes. It can be any types, but only takes 1 value.
  • You read the data from channel by using the arrow symbol (e.g: s := <-ch)
    • There is no space between the arrow and channel name.
  • You write the data into the channel by having the value pointing back to the channel (e.g: ch <- "Hello World")
• When reading data from the channel while it is empty, the process falls into "wait" mode instead of hogging the CPU, freeing up the CPU for other processes to run its work.
  • E.g. the main() uses s := <-ch to wait for delegates to signal back.
• It is not necessarily to close a channel. When a channel is no longer being referenced, it is garbage-collected.

Closing Channel

Although Go does not enforce one to close the channel, the threading design model does. Just because you are given the privilege not to close the channel does not mean you can kick the can down to the drain, expecting the garbage collector to figure out the messes. If there are large data inside the channel, you might be hogging the memory until the collector cleanses the channel memory.

To close a channel, simply use the keyword close(channel) (e.g. close(ch) shown above).

General Rules of Thumbs

Figuring out closing a channel is actually not hard. There are 4 axioms specified by Dave Cheney:

• A send to a nil channel blocks forever
• A receive from a nil channel blocks forever
• A send to a closed channel panics
• A receive from a closed channel returns the zero value immediately

There is no way to check a channel is closed or not without reading a value from it. Also, a channel is designed for single direction. Performing half-duplex or duplex communications requires a higher level of communications understanding like daisy-chain mechanism etc, which is outside of the scope for this page.

Sender Should Close Channel

Based on the axioms, it is always the best practice to close the channel from sender.

However, for "single receiver - multiple sender" case, it works differently.

Single/Multiple Receiver - Single/Multiple Sender

That being said, we have a 4 types of scenarios for setting up the channels:

1. single receiver - single sender
2. single receiver - multiple sender
3. multiple receiver - single sender (BAD)
4. multiple receiver - multiple sender (BAD)

Generally speaking, if you have multiple receivers, it signals you that you have a smelly communications design problem in you threading model. As analogous to our daily life, you don't accept multiple messages at a time over a single person: you get confused and not paying attention to it.

Therefore, #2 and #4 are not feasible. If you have such designs, you need to rethink your threading models and map out your delegation properly.

Hence, we always have single receiver, single/multiple senders:

• for single sender (case #1) - As described above:
  1. It is always the sender closes the channel.
• for multiple sender (case #2) - to prevent any sender panics due to sending message into a nil channel, you have multiple steps:
  1. You need another channel where there message is from "receiver -> sender"
  2. Have the receiver to send closing signal to all senders via "receiver -> sender" channel without closing the "sender -> receiver" channel.
  3. Each senders ends itself and signal the receiver of its exit without closing the "sender -> receiver" channel.
  4. Once receiver cross-checked and confirmed all the senders are ended, the receiver closes both the "sender -> receiver" and "receiver -> sender" channels.

Advanced Multi-treading - Single Receiver, Multiple Sender

Now, let's expand the from the single receiver - multiple sender. There are various ways to do it.

Responsibility Assignment Strategy

Here, you assign which thread responsible for which channel from the start. Here is an example:

package main

import (

        "fmt"

        "time"

)

func fibonacci(c, quit chan int) {

        x, y := 1, 1

        for {

                select {

                case c <- x:

                        x, y = y, x+y

                case <-quit:

                        fmt.Println("fibo: quit")

                        close(c)

                        return

                case <-time.After(5 * time.Second):

                        fmt.Println("fibo: run timeout")

                default:

                        fmt.Println("fibo: run default")

                }

        }

}

func subroutine(c, quit chan int) {

        for i := 0; i < 10; i++ {

                fmt.Println(<-c)

        }

        quit <- 0

        close(quit)

}

func main() {

        c := make(chan int)

        quit := make(chan int)

        squit := make(chan int)

        go subroutine(c, squit)

        go fibonacci(c, quit)

        <-squit

        quit <- 0

        close(quit)

}

Here is the phenomenons:

1. The main() creates 3 channels, the sender -> receiver channels (c, squit) and the receiver -> sender channel (quit).
   • c := make(chan int)
   • quit := make(chan int)
   • squit := make(chan int)
2. The main() proceed to run all delegates, both subroutines(...) and fibonacci(...)
   • go subroutine(c, squit)
   • go fibonacci(c, quit)
3. The main() waits for the squit signal from subroutines(...).
   • <-squit
4. fibonacci(...) calculates the value and send to sender->receiver channel c.
   • case c <- x:
   • x, y = y, x+y
5. subroutine(...) reads the data from sender->receiver channel c and printout for 10 times.
   • for i := 0; i < 10; i++ {
   • fmt.Println(<-c)
   • }
6. subroutine(...), tasked to close the channel squit, send quit signal to sender->receiver channel squit and then close the channel.
   • squit <- 0
   • close(quit)
7. main(), tasked to close the channel quit, receives squit signal, and then send quit signal to close fibonacci(...).
   • quit <- 0
8. fibonacci(...), tasked to close sender->receiver channel c, receives quit signal and executes its exit protocol if main() is still alive.
   • case <-quit:
   • fmt.Println("fibo: quit")
   • close(c)
   • return
9. main() exit program, killing both fibonnacci(...) and subroutine(...).

Some important points to remember:

• Always be clear with who is tasked to close which channel.
• When dealing with main() thread, you have to be extra careful since upon it exit, it kills all the goroutine abruptly.
• Always spins new 2 independent channels for 2 ways communications. You can save all these channels into a struct body or in a slice.
• Be sure to do clean up properly to avoid potential race conditions and dead locks.

1 Threads Governs All Channels

This is rarely used but workable, similar to sentinel looping approach. You have 1 thread (usually main()) that is responsible for all channels lifespan and communications while having the rest of the threads to do the work.

Concurrency Planning/Mapping

Another method is to have a clear plan that maps the concurrency execution and data access. This way, it can achieves all the objectives mentioned earlier. Here is a simple plan for the Philosopher & Chopstick problem.

There are 5 philosophers, 5 sets of chopsticks between them. Only 2 philosophers are allowed to eat at a time, and they can only eat a maximum of 3 times, reaching fullness.

That's all about concurrency in Go. Quite simple right?