Book Image

Effective Concurrency in Go

By : Burak Serdar
5 (1)
Book Image

Effective Concurrency in Go

5 (1)
By: Burak Serdar

Overview of this book

The Go language has been gaining momentum due to its treatment of concurrency as a core language feature, making concurrent programming more accessible than ever. However, concurrency is still an inherently difficult skill to master, since it requires the development of the right mindset to decompose problems into concurrent components correctly. This book will guide you in deepening your understanding of concurrency and show you how to make the most of its advantages. You’ll start by learning what guarantees are offered by the language when running concurrent programs. Through multiple examples, you will see how to use this information to develop concurrent algorithms that run without data races and complete successfully. You’ll also find out all you need to know about multiple common concurrency patterns, such as worker pools, asynchronous pipelines, fan-in/fan-out, scheduling periodic or future tasks, and error and panic handling in goroutines. The central theme of this book is to give you, the developer, an understanding of why concurrent programs behave the way they do, and how they can be used to build correct programs that work the same way in all platforms. By the time you finish the final chapter, you’ll be able to develop, analyze, and troubleshoot concurrent algorithms written in Go.
Table of Contents (13 chapters)

Debugging anomalies

Concurrent algorithms have a way of working when observed and failing when not. Many times, a program that runs just fine in a debugger fails mysteriously in production environments. Sometimes, such failures come with a stack trace, and you can track it back to why it happened. But sometimes, failures are much more subtle with no clear indication of what went wrong.

Consider the monitor in the previous section. You might want to find out why SlowFunc hangs. You cannot really run it in a debugger and step through the code because you simply have no control over which invocation of the function hangs. But what you can do is print a stack trace when it happens. This is the nature of most anomalies in concurrent programs: you don’t know when it is going to happen, but you can usually tell that it did. So, you can print all sorts of diagnostic information to backtrack how the program got there. For instance, you can print the stack trace when the monitor raises...