Concurrency primitives of Golang: how to use and how not to
Start time: 18:00 CEST
Co-founder and CTO at Last9.io
Every marginally, sophisticated Golang code that I write needs refactoring to solve race and deadlocks. The concurrency primitives like atomic, sync, channels, and waitGroups have their uses and fail. The lack of understanding ends up with a lot of rewrites. This talk aims to solve that.
I have seen more Go code shipped as glue programs and binaries than actual web servers, usually intended to do the heavy-lifting of data transfers shortly and reliably. With such clinical needs comes a need to handle concurrency and parallelism. And each time more than one worker is doing a job, there will be contention and starvation. A lack of useful design principle guides ends up in Engineers writing non-performant, race-condition prone codes or ending up refactoring.
To provide an example, some of the things I wish I had known:
- The real difference of when to use a Channel, a waitGroup, an atomic, or a mutex – one shouldn’t be using a wg.Add() inside a goroutine.
- How does one solve the problem of multiple listeners waiting on an event?
- How atomic Int operations can synchronize multiple workers signaling completion of work.
The talk is not limited to the above scenarios. It intends to cover a few of these constructs to reduce the refactoring that Golang engineers have to go through while also building a better understanding of distributed systems’ design patterns.
- What’s the difference among channel, wait group, atomic and mutex.
- How to use concurrency primitives.
- How to synchronize workers.
- How to prevent race conditions.
- How to design distributed systems.
Who it is for
Basic knowledge of Go language, wait groups, channels, mutexes and concurrency primitives concepts.
Certificate of attendance
A certificate of participation will be issued at the end of the sessionRegister for free