go-present.slide

Concurrency & Parallelism in Go

* Agenda :
- Brief introduction to Go
- Understand goroutines, waitgroups, mutexes & channels.
- Understanding concurrency and parallelism with the help of programs and visualisation
- High level overview of the Golang scheduler
- Gotchas of writing concurrent/parallel programs
- Success stories

* A Brief Introduction to Golang


* Golang
Go, also known as Golang, is an open-source, compiled, and statically typed programming language designed by Google. It is built to be simple, high-performing, readable, and efficient.

.play codeSamples/example.go


* Basic Go Code Example
Let's try to hit these websites and print the response in console.

.play codeSamples/websiteWithoutRoutines.go /START OMIT/,/END OMIT/


* GoRoutines

* A goroutine is a lightweight thread managed by the Go runtime.
- Memory consumption (very cheap around few kilobytes at inception)
- Dynamically Sized Stacks
- Low Latency (Run multiple Goroutines on a single OS thread)
- Setup and teardown costs
- Managed by go runtime

.image images/gofunc.jpeg 300 800

* Let's run printResponse function as goroutines

.play codeSamples/goroutines.go /START OMIT/,/END OMIT/

* The main function is a go routine
Even more important to know is that once the main function returns, it closes all other go routines that are currently running.

.image images/maingopher.jpeg 300 800


* Main & goroutines

.image images/main.gif 400 800


* Let's wait for go routines to finish.

.play codeSamples/goroutines-sleep.go /START OMIT/,/END OMIT/


* Wait-Groups

* To wait for multiple goroutines to finish, we can use a wait group.

.play codeSamples/waitGroup.go /START OMIT/,/END OMIT/

* Mutexes

* Mutex
A Mutex ensures ownership of a resource to one goroutine at a time

.play codeSamples/mutex.go /START OMIT/,/END OMIT/
.image images/race.png 200 800

* Channels

* Channels can be thought as pipes through which goroutines communicate.
- Can send and receive values with the channel operator <-
- Blocking in nature
- Helps to synchronizing goroutines(signal mechanism)
- Buffered & Unbuffered channels
- Can be used in Parallelization

.image images/channelsgopher.jpeg 300 500

* Channels
Adding channel to get the responses instead of an array.

.code codeSamples/channels.go /START OMIT/,/END OMIT/

.play codeSamples/channels2.go /START OMIT/,/END OMIT/

* Any questions until now?

.image images/questionsgopher.jpeg 400 600

* Understanding Concurrency & Parallelism

* Recap of Concurrency
- Dealing with a lot of things at the same time
- It is more about the structure of your program
- Can use one or more CPU cores

* Example (Concurrency)

.play codeSamples/pingpong.go /START OMIT/,/END OMIT/

* Visualising ping pong match

.image images/conc_latest.gif

* Recap of Parallelism
- Doing a lot of things at the same time
- Can only be achieved in multi core systems (unless hyper-threading is enabled)
- E.g - Coding and listening to music at the same time

* Example (Parallelism)

.play codeSamples/fib.go /START OMIT/,/END OMIT/

* Visualising fibonnaci calculation

.image images/par_lat.gif

* Concurrency with parallelism
- It is possible to run your concurrent code in parallel
- An example would be running multiple pingpong matches at the same time

* So when should we use what?
- There is no silver bullet, it depends on the problem you're solving
- For CPU heavy tasks use parallelism
- For network/IO heavy tasks use concurrency

* Questions until now?

.image images/questionsgopher.jpeg 400 600


* The Go Scheduler

* Responsibility

- Schedules N number of goroutines on M number of OS threads (M:N scheduling)
- Uses cooperative scheduling instead of preemptive scheduling (until Go 1.13)
- Context switching
- Written in Go


* M:P Threading

.image images/m-n.png 500 800


* Go Routines States

.image images/m-n1.png 500 800



* How do OS threads know where to pick up goroutines from?

.image images/gopher-thinking.png 300 500



* How do OS threads know where to pick up goroutines from?

- Local Run Queue (LRQ)
- Global Run Queue (GRQ)


* Where does these Local Run Queues exist?

.image images/gopher-thinking.png 300 500


* The Processor(P) object

- P : represents the processor, which can be seen as a local scheduler running on a thread
- Created when program starts
- Resource required by OS threads to run Go code
- Stores goroutines that are runnable (LRQ)

.image images/p.png 250 200


* M:P:N threading

.image images/MNP.png 550 1000


* Where does the Go Scheduler fit in?

.image images/exe.png


* What does this scheduler bring to the table?
- Better visibility of goroutine scheduling
- Reuse of OS threads
- Minimal context switching at OS level


* Questions until now?

.image images/questionsgopher.jpeg 400 600


* Gotchas

* Gotchas of Concurrent/Parallel programs
- Spawning many goroutines will *not* always give you better performance
- Goroutine leaks
- Increasing GOMAXPROCS value does *not* mean your code will run faster
- Shared memory for local variables can lead to undesired state
- Cooperative scheduling can starve goroutines


* Sucess Stories

* Uber

.image images/uber.png 500 800

* Twitch

.image images/twitch.png 500 1000

* Others

.image images/twitter.png 500 900

* That's all from our side.

.image images/micdrop.png 600 600