# goroutines Published articles for goroutines. This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles. ## Redesigning Kubernetes Workqueues and Resyncs to Reduce Thundering Herd Effects DevFeed: [Redesigning Kubernetes Workqueues and Resyncs to Reduce Thundering Herd Effects]() Original publisher: [Read original article]() Published: 2026-09-02T00:00:00Z Content type: article Language: en Sources: [Chainguard: Unchained]() Topics: [Kubernetes](), [systems](), [Concurrent Programming](), [Latency](), [Maintainers]() Tags: [architecture](), [concurrent](), [defense-in-depth](), [failover](), [goroutines](), [kubernetes](), [latency](), [maintainers](), [reconciliation](), [thundering-herd]() ### AI overview This article explains how Kubernetes controllers can experience thundering herd effects when restarts, leader failovers, or periodic resyncs cause many keys to enter an in-memory workqueue at once. It describes the queue and informer behavior behind the problem and introduces Chainguard's redesign of workqueues and resyncs to improve reconciliation under these conditions. ### Source excerpt The thundering herd is an architecture problem. See how Chainguard redesigned workqueues and resyncs to keep reconciliation running smoothly. ## Concurrent Servers: Part 8 - Go DevFeed: [Concurrent Servers: Part 8 - Go]() Original publisher: [Read original article]() Author: Eli Bendersky Published: 2026-08-22T14:52:00Z Content type: tutorial Language: en Sources: [Eli Bendersky]() Topics: [Go Language](), [Concurrency](), [Server](), [Concurrent Programming](), [Network]() Tags: [capacity](), [concurrency](), [concurrent](), [go](), [goroutines](), [misc](), [network-programming](), [servers](), [threads]() ### AI overview Part 8 of a series on concurrent network servers explains how Go implements sequential and concurrent servers. It demonstrates serving each client with a lightweight goroutine and discusses why concurrency may still need to be limited, including when tasks compete for finite CPU capacity. ### Source excerpt This is part 8 in a series of posts on writing concurrent network servers. In this part, we'll switch to Go and see how it tackles the challenges described earlier in the series. All posts in the series: Part 1 - Introduction Part 2 - Threads Part 3 - Event-driven Part 4 - libuv ... ## Context Package Semantics In Go DevFeed: [Context Package Semantics In Go]() Original publisher: [Read original article]() Published: 2025-02-10T00:00:00Z Content type: tutorial Language: en Sources: [William Kennedy]() Topics: [Go Language](), [context](), [Programming](), [Software]() Tags: [api](), [ardan-labs](), [blog](), [cancellation](), [go](), [go-programming](), [golang](), [goroutines](), [latency](), [pitfalls](), [programming]() ### AI overview This tutorial explains the semantics of Go's Context package, including request-scoped data, deadlines, cancellation signals, and how to introduce contexts early when designing APIs. It also discusses managing goroutine lifetime and latency in services. ### Source excerpt Although first introduced in 2014, the Context package remains a crucial component of Go programming, enabling efficient management of request-scoped data, deadlines, and cancellation signals. As the Go ecosystem continues to evolve, understanding the Context package's semantics is vital for developing reliable and maintainable software. This blogpost provides an in-depth exploration of the Context package's semantics, highlighting best practices and common pitfalls to help developers effectively leverage this powerful tool. ## Snapshotting in a high throughput shared nothing database DevFeed: [Snapshotting in a high throughput shared nothing database]() Original publisher: [Read original article]() Published: 2025-01-27T00:00:00Z Content type: tutorial Language: en Sources: [Gaurav Sarma's Blog]() Topics: [Database](), [Go Language](), [in-memory database](), [Concurrent Programming](), [Redis]() Tags: [database](), [go](), [golang](), [goroutines](), [in-memory-database](), [monitoring](), [redis](), [single-threaded]() ### AI overview This article explains the requirements and design considerations for adding point-in-time snapshots to a high-throughput, shared-nothing in-memory database written in Go. It examines copying data during writes, compares the approach with Redis's copy-on-write snapshotting, and begins testing copy-on-write behavior in a Go process. ### Source excerpt . [Snapshotting in a High-Throughput Shared-Nothing Database](snapshotting-in-a-high-throughput-shared-nothing-database-cover... ## Building a Scalable Job Consumer System in Go DevFeed: [Building a Scalable Job Consumer System in Go]() Original publisher: [Read original article]() Author: ansu jain Published: 2024-10-16T06:48:50Z Content type: tutorial Language: en Sources: [Mindorks - Medium]() Topics: [Go Language](), [Amazon Simple Queue Service (SQS)](), [Concurrency](), [Orchestration]() Tags: [consumer](), [go](), [goroutines](), [message-queue](), [orchestration](), [parallel](), [sqs](), [workers]() ### AI overview This tutorial presents a scalable job consumer system in Go. It describes interfaces for queue consumption, job management, job handling, and configuration, with parallel workers processing messages from queues such as AWS SQS. ### Source excerpt In this article, I will walk through the design of a scalable and extensible job consumer system using Go. This system allows the flexible registration of different jobs and the parallel consumption of messages from a message queue. I'll focus on how this system can be used to handle real-world scenarios like payment processing, order proccesing etc where different jobs consume messages from a queue (e.g., AWS SQS) and execute business logic based on the type of message received. Key Components of the Design IMessageConsumer - A generic interface for interacting with message queues (e.g., SQS). IJobManager - An interface that coordinates jobs and workers, responsible for consuming messages and distributing them to registered jobs. IJobHandler - An interface representing individual jobs. Each job implements specific business logic. IQueueConfig - Provides configurations for the queue (e.g., queue name, region, broker type). IJobConfig - Provides job-level configurations (e.g., number of consumers, timeouts). Core Concepts1. IMessageConsumer This interface abstracts queue operations, exposing methods for dequeuing and deleting messages. It's implemented by specific brokers (such as SQS in this case). Here's a basic structure: type IMessageConsumer interface { Dequeue(noOfMessages int64) ([]Message, error) Delete(messageIdentifier string) error } Dequeue: Fetches messages from the queue. Delete: Deletes a message after it has been successfully processed. 2. IJobManager This is where the system's core orchestration happens. The JobManager manages a pool of registered jobs and starts multiple workers to process messages concurrently. It uses a Consume method to begin processing and a RegisterJob method to register jobs into the system. type IJobManager interface { Consume(ctx context.Context) RegisterJob(job IJobHandler) } RegisterJob: Adds a job to the manager's job list. Consume: Starts the workers that process messages from the queue in parallel for each registered jo ## Ep. 6: GoRoutines and Error Handling: Essential Techniques for Software Engineers DevFeed: [Ep. 6: GoRoutines and Error Handling: Essential Techniques for Software Engineers]() Original publisher: [Read original article]() Published: 2024-06-14T00:00:00Z Content type: tutorial Language: en Sources: [William Kennedy]() Topics: [Concurrency](), [Go Language](), [Error Handling](), [HTTP]() Tags: [best-practices-in-go-concurrency](), [concurrency](), [concurrent-computing-in-go](), [controlled-goroutine-shutdown](), [error-handling](), [go](), [go-application-integrity](), [go-application-performance](), [go-application-reliability](), [go-concurrency-model](), [go-concurrent-processing](), [go-data-transaction-management](), [go-development-strategies](), [go-error-handling](), [go-http-package-shutdown](), [go-parent-child-goroutines](), [go-programming-best-practices](), [go-programming-for-software-engineers](), [go-programming-tutorials](), [go-structured-hierarchy](), [goroutine-debugging](), [goroutine-error-handling](), [goroutine-hierarchy](), [goroutine-termination-techniques](), [goroutines](), [high-stakes-data-transactions-in-go](), [managing-goroutines](), [orphan-goroutines](), [processes](), [resilient-error-handling-in-go](), [robust-go-error-handling](), [structured-goroutine-management](), [ultimate-software-design-series]() ### AI overview This installment of the Ultimate Software Design series explains how to manage goroutine parent-child relationships, terminate goroutines in an orderly way, and implement error handling for concurrent Go applications. It also discusses controlled shutdown using Go's HTTP package. ### Source excerpt Introduction: Continue the dive into the complexities of Go's concurrency model in this segment of the "Ultimate Software Design" series, where Bill shares essential techniques for managing GoRoutines. Here are three fresh takeaways: Understand the critical role of maintaining proper parent-child relationships in GoRoutine operations to avoid unexpected behaviors and system failures. Gain insights into structured techniques for terminating GoRoutines, ensuring that all child processes complete before their parent terminates, to maintain operational integrity. ## Ep. 5: Efficient Concurrency in Go: Managing GoRoutines and Load Shedding DevFeed: [Ep. 5: Efficient Concurrency in Go: Managing GoRoutines and Load Shedding]() Original publisher: [Read original article]() Published: 2024-06-11T00:00:00Z Content type: tutorial Language: en Sources: [William Kennedy]() Topics: [Concurrency](), [Go Language](), [Concurrent Programming](), [HTTP](), [servers]() Tags: [best-practices](), [concurrency](), [go](), [goroutines](), [http](), [http-server](), [kubernetes-clusters](), [load](), [managing-goroutines](), [networking](), [programming](), [server]() ### AI overview This video tutorial explains how to manage goroutines in Go using parent-child relationships, clean shutdown APIs, and load shedding. It focuses on preventing orphaned goroutines, protecting data consistency during shutdowns, and gracefully handling HTTP server traffic. ### Source excerpt Introduction: In this installment, Bill delves into the concept of load shedding in Go, explaining its importance in managing GoRoutines and ensuring clean shutdowns. How to manage GoRoutines using a parent-child relationship model to prevent orphan GoRoutines. The role of load shedding in maintaining clean and orderly shutdowns, particularly using the HTTP package in Go. Strategies for implementing GoRoutines in Go to handle concurrent tasks efficiently without risking data corruption during shutdowns. ## Microblog: TestMain can cause one to question reality DevFeed: [Microblog: TestMain can cause one to question reality]() Original publisher: [Read original article]() Author: Dave Cheney Published: 2024-02-21T21:04:26Z Content type: opinion Language: en Sources: [Dave Cheney]() Topics: [Go Language](), [test](), [bug](), [Logging]() Tags: [bug](), [go](), [goroutines](), [logging](), [test](), [testing](), [tests]() ### AI overview A one-line change caused a Go test to appear as though a failing test was not failing or being run. Attempts to change Go versions and run the tests elsewhere did not resolve the issue; a commented-out check and a logging library that spawns background goroutines were involved. ### Source excerpt This morning a one line change had several of us tearing up the fabric of reality trying to understand why a failing test wasn't failing, or, in fact, being run at all. Increasingly frantic efforts to upgrade/downgrade Go, run the tests on another machine, run the tests in CI, all served to only unnerve us [...] ## Measuring cost of spawning Goroutines DevFeed: [Measuring cost of spawning Goroutines]() Original publisher: [Read original article]() Published: 2023-09-17T00:00:00Z Content type: article Language: en Sources: [Gaurav Sarma's Blog]() Topics: [Concurrency](), [Benchmark](), [Go Language](), [Concurrent Programming]() Tags: [benchmark](), [concurrency](), [go](), [goroutines](), [measuring]() ### AI overview This article revisits a Go benchmark measuring goroutine-spawning patterns. The corrected experiment separates channel synchronization costs from goroutine creation and finds that the original conclusion favoring preallocated worker pools was imprecise. ### Source excerpt > 2026 update. The original version of this post compared three concurrency shapes by timing fixed batches of 1M / 10M / 100M / 1B operations and concluded "always pre-allocate... ## Six-Month Update on Life at Temporal DevFeed: [Six-Month Update on Life at Temporal]() Original publisher: [Read original article]() Author: Sergey Bykov Published: 2021-03-31T04:00:00Z Content type: opinion Language: en Sources: [Temporal Blog]() Topics: [Development](), [Go Language](), [macOS](), [Windows](), [WSL2](), [Concurrency](), [IntelliJ IDEA](), [rider](), [goland](), [Docker](), [IoC (Disambiguation)](), [ASP.NET]() Tags: [c-sharp](), [code](), [community](), [concurrency](), [cross-platform](), [debugging](), [development](), [go](), [goland](), [goroutines](), [intellij](), [jetbrains](), [linux](), [macos](), [rider]() ### AI overview A six-month update on the author's transition from corporate work to startup life at Temporal, covering experiences with macOS, Windows, Linux, JetBrains IDEs, and Go. ### Source excerpt I wrote about how it started in Why I Joined Temporal. Somebody suggested I should post an update about how things are six months later. How am I feeling after jumping from a corporate cliff into the whitewater of startup life? ## When Language Runtime Scheduling Fails in Multi-Tenant Services DevFeed: [When Language Runtime Scheduling Fails in Multi-Tenant Services]() Original publisher: [Read original article]() Author: sasha@goteleport.com (Alexander Klizhentas) Published: 2020-12-03T00:00:00Z Content type: article Language: en Sources: [Teleport]() Topics: [Programming](), [Concurrency](), [Go Language](), [Multitenancy](), [Software as a service]() Tags: [concurrency](), [go](), [goroutines](), [memory](), [multi-tenancy](), [outage](), [performance](), [pitfalls]() ### AI overview The article examines how language runtime scheduling can affect multi-tenant services. It uses Go examples to explain concurrent network workloads and shows how CPU-intensive work can let one tenant consume resources and degrade performance for others. ### Source excerpt Explore edge-cases in which programming language runtimes fail to provide fair resource scheduling that leads to outages. ## Inlining optimisations in Go DevFeed: [Inlining optimisations in Go]() Original publisher: [Read original article]() Author: Dave Cheney Published: 2020-04-25T06:38:17Z Content type: article Language: en Sources: [Dave Cheney]() Topics: [Go Language](), [Compiler](), [Code]() Tags: [compilation](), [compiler](), [compilers](), [function](), [go](), [goroutines](), [inlining](), [optimisation](), [performance](), [programming]() ### AI overview This article explains how the Go compiler implements function inlining and how the optimization affects Go code. It focuses on gc, the de facto Go compiler from golang.org, while noting that other Go compilers may differ in implementation and effectiveness. ### Source excerpt This is a post about how the Go compiler implements inlining and how this optimisation affects your Go code. n.b. This article focuses on gc, the de facto Go compiler from golang.org. The concepts discussed apply broadly to other Go compilers like gccgo and tinygo but may differ in implementation and efficacy. What is inlining? [...] ## Concurrency Trap #2: Incomplete Work DevFeed: [Concurrency Trap #2: Incomplete Work]() Original publisher: [Read original article]() Published: 2019-04-18T00:00:00Z Content type: tutorial Language: en Sources: [William Kennedy]() Topics: [Concurrency](), [Go Language](), [integrity](), [Latency]() Tags: [ardan-labs](), [asynchronous](), [blog](), [concurrency](), [go](), [go-programming](), [golang](), [goroutines](), [integrity](), [latency](), [programming]() ### AI overview This article explains incomplete work as a Go concurrency trap: a program exits when the main function returns without waiting for non-main goroutines, which can terminate important work prematurely. It discusses possible integrity problems, including database or filesystem corruption and data loss, and introduces an asynchronous event-tracking example motivated by latency concerns. ### Source excerpt Introduction In my first post on Goroutine Leaks, I mentioned that concurrency is a useful tool but it comes with certain traps that don't exist in synchronous programs. To continue with this theme, I will introduce a new trap called incomplete work. Incomplete work occurs when a program terminates before outstanding Goroutines (non-main goroutines) complete. Depending on the nature of the Goroutine that is being terminated forcefully, this may be a serious problem. ## Goroutine Leaks - The Abandoned Receivers DevFeed: [Goroutine Leaks - The Abandoned Receivers]() Original publisher: [Read original article]() Published: 2018-12-19T00:00:00Z Content type: tutorial Language: en Sources: [William Kennedy]() Topics: [Go Language](), [Memory Leaks]() Tags: [ardan-labs](), [blog](), [channel](), [developers](), [go](), [go-programming](), [golang](), [goroutines](), [leak](), [memory](), [memory-leaks](), [pipeline](), [programming]() ### AI overview This Go programming article explains a goroutine leak scenario in which multiple goroutines remain blocked waiting to receive values that will never be sent. It presents a batch-processing program using input and output channels, a goroutine worker pool, and a pipeline. ### Source excerpt Introduction Goroutine Leaks are a common cause of memory leaks in Go programs. In my previous post, I presented an introduction to Goroutine leaks and provided one example of a common mistake that many Go developers make. Continuing that work, this post presents another scenario on how Goroutines could be leaked. Leak: The Abandoned Receivers For this leak example you will see multiple Goroutines blocked waiting to receive values that will never be sent. ## Goroutine Leaks - The Forgotten Sender DevFeed: [Goroutine Leaks - The Forgotten Sender]() Original publisher: [Read original article]() Published: 2018-11-12T00:00:00Z Content type: tutorial Language: en Sources: [William Kennedy]() Topics: [Go Language](), [Concurrency](), [Concurrent Programming](), [Memory Leaks](), [Code]() Tags: [ardan-labs](), [blog](), [code-review](), [concurrency](), [concurrent-programming](), [go](), [go-programming](), [golang](), [goroutines](), [memory-leak](), [memory-management](), [performance](), [programming](), [review]() ### AI overview This article explains how goroutine leaks occur in Go concurrent programs. It describes a leak as a goroutine that is expected to terminate but remains blocked indefinitely, keeping its allocated memory for the lifetime of the application, and illustrates how a goroutine waiting on a channel can become unreachable when its calling function returns. ### Source excerpt Introduction Concurrent programming allows developers to solve problems using more than one path of execution and is often used in an attempt to improve performance. Concurrency doesn't mean these multiple paths are executing in parallel; it means these paths are executing out-of-order instead of sequentially. Historically, this type of programming is facilitated using libraries that are either provided by a standard library or from 3rd party developers. In Go, concurrency features like Goroutines and channels are built into the language and runtime to reduce or eliminate the need for libraries. This has created the illusion that writing concurrent programs in Go is easy. You must be cautious when deciding to use concurrency as it comes with some unique side effects or traps if not used correctly. These traps can create complexity and nasty bugs if you're not careful. ## The Behavior Of Channels DevFeed: [The Behavior Of Channels]() Original publisher: [Read original article]() Published: 2017-10-24T00:00:00Z Content type: tutorial Language: en Sources: [William Kennedy]() Topics: [Go Language](), [Code](), [Software]() Tags: [ardan-labs](), [blog](), [channel](), [concurrent](), [go](), [go-programming](), [golang](), [goroutines](), [how-to](), [programming](), [signal]() ### AI overview This tutorial explains Go channels as signaling mechanisms between goroutines rather than merely as queue-like data structures. It introduces guarantee of delivery, channel state, and signaling with or without data, and describes how buffered and unbuffered channels differ in delivery behavior. ### Source excerpt Introduction When I started to work with Go's channels for the first time, I made the mistake of thinking about channels as a data structure. I saw channels as a queue that provided automatic synchronized access between goroutines. This structural understanding caused me to write a lot of bad and complicated concurrent code. I learned over time that it's best to forget about how channels are structured and focus on how they behave. So now when it comes to channels, I think about one thing: signaling. A channel allows one goroutine to signal another goroutine about a particular event. Signaling is at the core of everything you should be doing with channels. Thinking of channels as a signaling mechanism will allow you to write better code with well defined and more precise behavior. ## Scheduler Tracing In Go DevFeed: [Scheduler Tracing In Go]() Original publisher: [Read original article]() Published: 2015-02-23T00:00:00Z Content type: tutorial Language: en Sources: [William Kennedy]() Topics: [Go Language](), [tracing](), [Concurrency](), [debugging]() Tags: [ardan-labs](), [blog](), [commands](), [concurrency](), [debugging](), [go](), [go-programming](), [golang](), [goroutines](), [profiling](), [programming](), [standard](), [tracing]() ### AI overview This tutorial explains how to use the GODEBUG environment variable to inspect Go runtime profiling and debugging information, with a focus on interpreting scheduler trace output from a concurrent program. ### Source excerpt Introduction One of the things I love about Go is the profiling and debug information you can generate. There is a special environmental variable named GODEBUG that will emit debugging information about the runtime as your program executes. You can request summary and detailed information for both the garbage collector and the scheduler. What's great is you don't need to build your program with any special switches for it to work. ## Ice Cream Makers and Data Races Part II DevFeed: [Ice Cream Makers and Data Races Part II]() Original publisher: [Read original article]() Published: 2014-06-27T00:00:00Z Content type: tutorial Language: en Sources: [William Kennedy]() Topics: [Go Language](), [race-condition](), [Code]() Tags: [ardan-labs](), [blog](), [code](), [go](), [go-programming](), [golang](), [goroutines](), [interface](), [memory](), [programming](), [race-condition]() ### AI overview This article examines a data race in Go caused by unsynchronized reads and writes to an interface-typed variable. It explains how partial writes can cause method implementations for different receiver types to operate on incompatible memory representations. ### Source excerpt Introduction Dave Cheney published a post called Ice Cream Makers and Data Races. The post showed an example of an interesting data race that can occur when using an interface typed variable to make a method call. If you have not read the post yet please do. Once you read the post you will discover that the problem lies with the fact that an interface value is implemented internally using a two word header and that the Go memory model states only writes to a single word are atomic. The program in the post shows a race condition that allows two goroutines to perform a read and write operation at the same time against an interface value. Not synchronizing this read and write allows the read to observe a partial write to the interface value. This allows the method implementation for the Ben type to operate against a value of the Jerry type and visa versa. In Dave's example, the layout of the Ben and Jerry structs were identical in memory, so they were in some sense compatible. Dave suggested the chaos that would occur if they had different memory representations. This is because each implementation of the Hello method assumes the code is operating against values of the receiver type. When this bug surfaces, this is no longer the case. To give you a visual view of this suggested chaos, I am going to change the declaration of the Jerry type in two different ways. Both changes will give you some better insight into the interworking of interface types and memory. First Code Change Let's review the code and see the first set of changes. My changes to the original code are in bold: ## Running MongoDB Queries Concurrently With Go DevFeed: [Running MongoDB Queries Concurrently With Go]() Original publisher: [Read original article]() Published: 2014-02-25T00:00:00Z Content type: tutorial Language: en Sources: [William Kennedy]() Topics: [Go Language](), [MongoDB](), [Programming](), [Code]() Tags: [ardan-labs](), [blog](), [concurrent](), [drivers](), [go](), [go-programming](), [go-types](), [golang](), [goroutines](), [mongodb](), [programming](), [programming-languages](), [support](), [writing-code]() ### AI overview A beginner-oriented tutorial on using Go's mgo driver to connect to MongoDB and run queries concurrently. It demonstrates launching ten goroutines, querying a collection, and unmarshaling returned documents into native Go types. ### Source excerpt If you are attending GopherCon 2014 or plan to watch the videos once they are released, this article will prepare you for the talk by Gustavo Niemeyer and Steve Francia. It provides a beginners view for using the Go mgo driver against a MongoDB database. Introduction MongoDB supports many different programming languages thanks to a great set of drivers. One such driver is the MongoDB Go driver which is called mgo. This driver has been externally developed by Gustavo Niemeyer from Canonical, and eventually Steve Francia, the head of the drivers team at MongoDB Inc, took notice and offered support. Both Gustavo and Steve will be talking at GopherCon 2014 in April about "Painless Data Storage With MongoDB and Go ". The talk centers around the mgo driver and how MongoDB and Go really work well together to build highly scalable and concurrent software. MongoDB and Go let us build scalable software on many different operating systems and architectures, without the need to install any frameworks or runtime environments. Go programs are native binaries and the Go tooling is constantly improving to create binaries that run as fast as equivalent C programs. That wouldn't mean anything if writing code in Go was complicated and as tedious as writing programs in C. This is where Go really shines because once you get up to speed, writing programs in Go is fast and fun. In this post I am going to show you how to write a Go program using the mgo driver to connect and run queries concurrently against a MongoDB database. I will break down the sample code and explain a few things that seem to be always be a bit confusing to those new to MongoDB and Go. Sample Program The sample program connects to a public MongoDB database I have hosted with MongoLab. If you have Go and Bazaar installed on your machine, you can run the program. The program launches ten goroutines that individually query all the records from the buoy_stations collection inside the goinggo database. The records are unma ## The Nature Of Channels In Go DevFeed: [The Nature Of Channels In Go]() Original publisher: [Read original article]() Published: 2014-02-17T00:00:00Z Content type: tutorial Language: en Sources: [William Kennedy]() Topics: [Go Language](), [Concurrency](), [Concurrent Programming]() Tags: [ardan-labs](), [blog](), [capacity](), [channel](), [concurrency](), [go](), [go-programming](), [golang](), [goroutines](), [programming](), [state](), [synchronization]() ### AI overview This tutorial explains Go channels as type-safe message queues that synchronize goroutines exchanging resources. It distinguishes unbuffered channels, which require both sender and receiver to be ready, from buffered channels, whose capacity affects when sends and receives block. ### Source excerpt Introduction In my last post called Concurrency, Goroutines and GOMAXPROCS, I set the stage for talking about channels. We discussed what concurrency was and how goroutines played a role. With that foundation in hand, we can now understand the nature of channels and how they can be used to synchronize goroutines to share resources in a safe, less error prone and fun way. What Are Channels Channels are type safe message queues that have the intelligence to control the behavior of any goroutine attempting to receive or send on it. A channel acts as a conduit between two goroutines and will synchronize the exchange of any resource that is passed through it. It is the channel's ability to control the goroutines interaction that creates the synchronization mechanism. When a channel is created with no capacity, it is called an unbuffered channel. In turn, a channel created with capacity is called a buffered channel. To understand what the synchronization behavior will be for any goroutine interacting with a channel, we need to know the type and state of the channel. The scenarios are a bit different depending on whether we are using an unbuffered or buffered channel, so let's talk about each one independently. Unbuffered Channels Unbuffered channels have no capacity and therefore require both goroutines to be ready to make any exchange. When a goroutine attempts to send a resource to an unbuffered channel and there is no goroutine waiting to receive the resource, the channel will lock the sending goroutine and make it wait. When a goroutine attempts to receive from an unbuffered channel, and there is no goroutine waiting to send a resource, the channel will lock the receiving goroutine and make it wait. View linked image: Screen Shot ## Concurrency, Goroutines and GOMAXPROCS DevFeed: [Concurrency, Goroutines and GOMAXPROCS]() Original publisher: [Read original article]() Published: 2014-01-29T00:00:00Z Content type: tutorial Language: en Sources: [William Kennedy]() Topics: [Concurrency](), [Go Language](), [Concurrent Programming](), [Programming](), [Processes]() Tags: [ardan-labs](), [blog](), [concurrency](), [concurrent](), [go](), [go-programming](), [golang](), [goroutines](), [main-thread](), [parallelism](), [processes](), [programming](), [threads]() ### AI overview This introductory Go article explains concurrent programs, distinguishes processes and operating-system threads, and introduces goroutines and the role of the GOMAXPROCS environment variable and runtime function in Go runtime behavior. ### Source excerpt Introduction When new people join the Go-Miami group they always write that they want to learn more about Go's concurrency model. Concurrency seems to be the big buzz word around the language. It was for me when I first started hearing about Go. It was Rob Pike's Go Concurrency Patterns video that finally convinced me I needed to learn this language. To understand how Go makes writing concurrent programs easier and less prone to errors, we first need to understand what a concurrent program is and the problems that result from such programs. I will not be talking about CSP (Communicating Sequential Processes) in this post, which is the basis for Go's implementation of channels. This post will focus on what a concurrent program is, the role that goroutines play and how the GOMAXPROCS environment variable and runtime function affects the behavior of the Go runtime and the programs we write. Processes and Threads When we run an application, like the browser I am using to write this post, a process is created by the operating system for the application. The job of the process is to act like a container for all the resources the application uses and maintains as it runs. These resources include things like a memory address space, handles to files, devices and threads. A thread is a path of execution that is scheduled by the operating system to execute the code we write in our functions against a processor. A process starts out with one thread, the main thread, and when that thread terminates the process terminates. This is because the main thread is the origin for the application. The main thread can then in turn launch more threads and those threads can launch even more threads. The operating system schedules a thread to run on an available processor regardless of which process the thread belongs to. Each operating system has its own algorithms that make these decisions and it is best for us to write concurrent programs that are not specific to one algorithm or the other ## Pool Go Routines To Process Task Oriented Work DevFeed: [Pool Go Routines To Process Task Oriented Work]() Original publisher: [Read original article]() Published: 2013-09-14T00:00:00Z Content type: tutorial Language: en Sources: [William Kennedy]() Topics: [Go Language](), [Concurrency](), [Concurrent Programming]() Tags: [ardan-labs](), [blog](), [cpu](), [go](), [go-programming](), [golang](), [goroutines](), [memory](), [performance](), [performance-tuning](), [programming](), [resource](), [threads]() ### AI overview This article explains the Work Pool pattern in Go for processing task-oriented work. It describes queuing tasks, reusing available goroutines, configuring pool and queue capacity, and tuning resource use and application performance. ### Source excerpt After working in Go for some time now, I learned how to use an unbuffered channel to build a pool of goroutines. I like this implementation better than what is implemented in this post. That being said, this post still has value in what it describes. External resource on github.com: https://github.com/goinggo/work On more than one occasion I have been asked why I use the Work Pool pattern. Why not just start as many Go routines as needed at any given time to get the work done? My answer is always the same. Depending on the type of work, the computing resources you have available and the constraints that exist within the platform, blindly throwing Go routines to perform work could make things slower and hurt overall system performance and responsiveness. Every application, system and platform has a breaking point. Resources are not unlimited, whether that is memory, CPU, storage, bandwidth, etc. The ability for our applications to reduce and reuse resources is important. Work pools provide a pattern that can help applications manage resources and provide performance tuning options. Here is the pattern behind the work pool: ## Thread Pooling in Go Programming DevFeed: [Thread Pooling in Go Programming]() Original publisher: [Read original article]() Published: 2013-05-31T00:00:00Z Content type: tutorial Language: en Sources: [William Kennedy]() Topics: [Concurrency](), [Go Language](), [servers](), [Programming](), [.NET](), [C#](), [C++](), [win32]() Tags: [ardan-labs](), [blog](), [concurrency](), [development](), [go](), [go-programming](), [golang](), [goroutines](), [process](), [programming](), [server](), [thread](), [threads](), [win32]() ### AI overview This article introduces thread pools for server development and discusses how to tune pool size and concurrency. It describes queuing work for a fixed number of worker threads, explains why creating a new thread for every task can harm performance, and relates the approach to Go goroutines and unbuffered channels, with comparisons to Microsoft-stack development. ### Source excerpt After working in Go for some time now, I learned how to use an unbuffered channel to build a pool of goroutines. I like this implementation better than what is implemented in this post. That being said, this post still has value in what it describes. External resource on github.com: https://github.com/goinggo/work Introduction In my world of server development thread pooling has been the key to building robust code on the Microsoft stack. Microsoft has failed in .Net by giving each Process a single thread pool with thousands of threads and thinking they could manage the concurrency at runtime. Early on I realized this was never going to work. At least not for the servers I was developing. When I was building servers in C/C++ using the Win32 API, I created a class that abstracted IOCP to give me thread pools I could post work into. This has always worked very well because I could define the number of threads in the pool and the concurrency level (the number of threads allowed to be active at any given time). I ported this code for all of my C# development. If you want to learn more about this, I wrote an article years ago (External resource on theukwebdesigncompany.com: http://www.theukwebdesigncompany.com/articles/iocp-thread-pooling.php). Using IOCP gave me the performance and flexibility I needed. BTW, the .NET thread pool uses IOCP underneath. The idea of the thread pool is fairly simple. Work comes into the server and needs to get processed. Most of this work is asynchronous in nature but it doesn't have to be. Many times the work is coming off a socket or from an internal routine. The thread pool queues up the work and then a thread from the pool is assigned to perform the work. The work is processed in the order it was received. The pool provides a great pattern for performing work efficiently. Spawning a new thread everytime work needs to be processed can put heavy loads on the operating system and cause major performance problems. So how is the thread pool p