DEV Community: Silver_dev

Golang. M:P:G Model

Silver_dev — Sun, 15 Mar 2026 23:32:47 +0000

The M:P:G model is the core of Go's concurrency model, and it is one of the most efficient among modern programming languages.

It provides:

Efficient CPU core utilization through a fixed number of P's (Processors).
Scalability to hundreds of thousands of goroutines via lightweight G's (Goroutines).
Transparent handling of blocking operations through dynamic management of M's (OS Threads).
Intelligent load balancing using work stealing and spinning threads.

Go abstracts you away from low-level OS thread management, but not from concurrent programming itself. Your task is to design the system by defining the correct concurrency boundaries and synchronization points, while the M:P:G model takes care of efficient execution.

G (Goroutine) — Lightweight Execution Unit

A goroutine is not an operating system thread; it's a runtime-level abstraction representing a lightweight thread of control with minimal overhead.

Initial Stack Size: 2 KB (roughly 1000 times smaller than an OS thread).
Context Switch Overhead: ~200 ns (5-10 times faster than switching OS threads).
Placement: A goroutine is placed into the local run queue of the logical processor (P) designated to execute it.

What is G from the Runtime's Perspective?
It's a data structure that describes the execution state of a single function. It is not rigidly tied to any specific OS thread (M).

Key Fields of the g Struct:

stack: Describes the goroutine's stack memory.
- lo and hi: The lower and upper bounds of the stack in memory.
- guard: Used for stack overflow detection.
- Important: A goroutine's stack starts small (e.g., 2 KB) and grows dynamically (by being copied to a new memory location) as needed.
sched: This field is far more critical than it might initially seem. It's a gobuf structure that saves the execution context (CPU register state) when the goroutine is not running. When a goroutine is paused (parked), it saves its sp (stack pointer), pc (program counter), bp (base pointer), and other registers here. When execution resumes, it restores them from here. This is the essence of "lightweight" switching — switching between G's involves saving and restoring a few dozen bytes in memory, not making an expensive kernel system call.
atomicstatus: The current state of the goroutine.
- _Gidle: Just allocated, but hasn't run yet.
- _Grunnable: Ready to run, currently in a run queue.
- _Grunning: Currently executing on an M and P.
- _Gsyscall: Executing, but inside a system call.
- _Gwaiting: Blocked (waiting on a channel, mutex, or network I/O).
- _Gdead: Not in use (held in a pool for reuse to avoid allocations).
- _Gcopystack: Temporary state used while resizing (copying) the stack.
m: A pointer to the M struct (OS thread) if the goroutine is running (_Grunning) or was interrupted during a system call (_Gsyscall). Otherwise, it's nil.
waitreason: If the status is _Gwaiting, this field holds a string explaining the reason for blocking (e.g., "chan receive").

A goroutine knows nothing about CPU cores or OS threads. Its world consists of its stack, its saved registers, and the queue it resides in. It essentially says: "I have code that needs to be executed, and a context (registers/stack) from which to start or continue."

P (Processor) — The Conductor

P is an abstraction of a logical processor, the connecting link between M (OS thread) and G (goroutine). This is the most important and uniquely Go concept. P is not a physical CPU core, but a logical resource required to execute Go code.

What is P from the Runtime's Perspective?
It is a scheduling and resource allocation context. Without a P, an M has an OS thread but no "permission" to execute goroutine code (except in special cases, like the g0 system stack).

Key Fields of the p Struct:

runq: The Local Run Queue. This is a fixed-size circular buffer (typically 256 elements). Goroutines with the status _Grunnable are placed here.
runnext: A pointer to the next goroutine to be executed. This is an optimization, particularly for channel operations. When a goroutine becomes unblocked (e.g., after a channel send), it is often placed here to be executed immediately as the next step on the same P. This gives priority to recently unblocked goroutines.
mcache: The local memory allocation cache. Memory allocation in Go is very fast because each P has its own cache (mcache) for small objects. This allows goroutines on different Ps to allocate memory without global locks.
status: The state of the P.
- _Pidle: Not currently in use.
- _Prunning: Bound to an M and executing code.
- _Psyscall: Bound to an M, but that M is currently inside a system call.
- _Pgcstop: Stopped for garbage collection.
- _Pdead: No longer in use.
schedtick, syscalltick: Counters for statistics and for detecting "stuck" goroutines.

P is the main arbiter of resources. The number of P's determines the degree of parallelism.

If you have 4 P's, then a maximum of 4 goroutines can be executing simultaneously (in parallel) at any given moment.
P decouples M and G. Thanks to P, an M doesn't need to know which goroutines are running on other Ms. Each P only concerns itself with its own queue.
When garbage collection (GC) starts, all P's are stopped (_Pgcstop), guaranteeing that no goroutine is mutating memory during the "stop the world" (STW) phase.

Key Characteristics

Number of P's:
- Determined by GOMAXPROCS (defaults to the number of CPU cores).
- Fixed for the lifetime of the program (can be changed via runtime.GOMAXPROCS).
- Important: This is NOT the maximum number of concurrent operations, but the number of execution contexts.
Local Run Queue:
- Size: 256 elements (circular buffer).
- Lock-free access (no mutexes) for the currently bound M.
- Uses the "work stealing" algorithm for load balancing.
At Program Startup:
- GOMAXPROCS instances of P are created.
- Each P receives its own local run queue for goroutines.
- When a goroutine is created, it is placed into the queue of the current P.

// Distribution example
P0: [G1, G2, G3, G4]
P1: [G5, G6]
P2: []
P3: [G7, G8, G9]

Work Stealing in Action

When P0 finishes executing goroutines and its local queue is empty:
It first checks the global run queue.
If the global queue is empty, it "steals" approximately half of the goroutines from another P's queue (e.g., P3).
Algorithm: The stealing starts from the middle of the victim's queue, not the beginning, to ensure better load balancing.

Data Locality: The local queue reduces contention (lock contention) and improves cache efficiency.
Load Balancing: Work stealing ensures an even distribution of workload across available P's.
Potential Pitfall: Setting GOMAXPROCS too high (significantly exceeding the number of physical CPU cores) can increase overhead due to more frequent stealing attempts and context switching.

M (Machine) — The Executor

If G represents the "work," then M represents the "worker." It is a direct representation of an operating system thread. M is the OS thread that actually executes machine code. It serves as the crucial link between the OS and the Go runtime.

What is M from the Runtime's Perspective?
It's a structure that manages a single OS thread. M is the only entity that actually executes anything.

Key Fields of the m Struct:

g0: A pointer to a special goroutine called g0. This is the most important concept for understanding M's operation.
- Every M has its own dedicated g0 goroutine.
- Why is it needed? The code running in a regular goroutine (G) is "user" code. However, the code for the scheduler, the garbage collector, and signal handling is "system" (runtime) code. When M needs to execute scheduler code (e.g., to choose the next G to run), it switches to its g0 stack. This is a separate stack allocated specifically for runtime tasks.
- This separation is critical for safety: user code cannot accidentally or maliciously corrupt the scheduler's stack, and vice versa. Switching between a user G and g0 is done via the runtime·mcall or runtime·systemstack mechanisms.
curg: A pointer to the current user goroutine being executed. If M is executing on its g0 stack, curg might be nil or point to the goroutine that was preempted.
p: A pointer to the Processor (P) to which this M is currently attached. If M is idle or inside a system call without a P, this field can be nil.
nextp, oldp: Used for temporarily holding a P during transitions (e.g., while entering or exiting a system call).
spinning: A flag indicating that this M is actively seeking work even though its associated P's queue is empty. This is an important optimization for load balancing.
park: A structure used to park (put to sleep) the M itself when there is absolutely no work to do.

M lives in two worlds simultaneously. It executes both user code (on the curg stack) and runtime code (on the g0 stack). The switching between these modes happens very frequently and must be extremely fast. This is where the magic of "lightweight" goroutines occurs: M switches between different G's, saving the context of one and loading the context of another, all while remaining the same underlying OS thread.

Key Characteristics

M-to-P Relationship:
- At any given moment, an M can be attached to at most one P.
- The number of M's can exceed the number of P's.
- Maximum number of M's: ~10,000 (limited by maxmcount).
M States:
- Spinning: Actively searching for work (high priority).
- Idle: Idle, but can be activated if work appears.
- Blocked: Blocked in the OS (e.g., during a system call).
Special M's:
- M0: The first OS thread created and run when the program starts.
- G0: A special goroutine for running system code on each M (one per M).
- Sysmon: The system monitor (a dedicated M for background tasks like network polling, preemption, and GC triggering).

How It Looks in Action

Scenario 1: Normal Execution

M1 is attached to and executing on P1.
P1 processes goroutines from its local run queue.
M1 executes the goroutine's code on its curg stack.

Scenario 2: Blocking System Call

A running goroutine G2 makes a blocking system call and transitions to the _Gsyscall state.
M1 (which was running G2) detaches itself from its P (P1). P1 is now free (_Pidle).
Another M (e.g., M2) can now acquire the now-idle P1 and continue executing other goroutines from P1's local queue, preventing the CPU core from sitting idle.

Scenario 3: Recovery After a System Call

When the blocking system call (e.g., a network request) completes for G2:
M1 (which was blocked with G2) attempts to re-acquire its original P, P1.
If P1 is now busy (being used by M2), M1 cannot get it back immediately. It places G2 into the global run queue.
The sysmon thread or another spinning M will eventually notice G2 in the global queue and wake up or direct an idle M to handle G2.

The "Spinning Threads" Mechanism

The Go runtime uses heuristics to maintain "hot" (spinning) threads to minimize latency.

Spinning M: OS threads that are actively searching for work (checking local/global queues, attempting work stealing) even though they aren't currently executing a goroutine.
Goal: To minimize the delay (latency) when new tasks become available. A spinning M can pick up a new task immediately without waiting for an idle thread to wake up.
Algorithm:
- If there are idle P's (available CPU capacity) and no spinning M's currently looking for work, the runtime may create a new spinning M.
- A spinning M searches for work for a short period (approximately 10 microseconds).
- If it doesn't find any work within that time, it eventually transitions to an idle state and is parked to save power/CPU.
Efficiency: Spinning M's significantly reduce latency when new tasks appear.
Overhead: Too many spinning M's would waste CPU cycles.
Limitation: The number of spinning M's is automatically and dynamically regulated by the runtime based on the current load and available work.

Key Interactions

Goroutine Creation (go func()):
- The new goroutine (G) is placed into the local run queue of the current P.
- If the local queue is full, part of its contents (along with the new G) is moved to the global run queue to make space.
Goroutine Execution (Scheduling Cycle):
- An M must acquire (or already be attached to) a P.
- It retrieves a runnable goroutine (G) from the P's local run queue (checking runnext first, then the circular buffer runq).
- If the local queue is empty, it attempts work stealing from other P's or checks the global queue.
- The M executes the goroutine's code on its curg stack. Execution continues until the goroutine blocks, makes a system call, is preempted (due to running too long), or voluntarily yields.

Overhead Metrics

Operation	Time (Go 1.20)	Notes
Goroutine Creation	~200 ns	Including stack allocation
Goroutine Context Switch	~200 ns	Without a system call
Blocking System Call	~500 ns	Including parking the goroutine
Network Operation (Non-blocking)	~100 ns	Handled via the netpoller

M:P:G Interaction — A Simplified Analogy

When you write go func() { ... }(), you are creating a G.

The runtime places this G into the queue of some P (or the global queue, if necessary).
The M (OS thread) attached to that P is awakened (if idle) and executes the code of G.
If G makes a blocking system call, the M detaches from its P. The P, now free, can find (or be picked up by) another M to continue executing other G's from its queue.
If G simply runs a CPU-bound loop for ~10ms, the scheduler preempts it and hands control over to another G waiting in the P's local queue.

To solidify this concept, imagine a factory representing the Go process:

G (Goroutine) — is a task or job (like a blueprint and materials on a small, dedicated work table). There can be thousands of these tasks.

M (Machine) — is a worker. Each worker has their own personal toolbox (the g0 stack) for performing internal, system-level tasks needed to manage the jobs.

P (Processor) — is a workbench. On the workbench, there is a list (local queue) of jobs waiting to be done, and a special spot (runnext) for the most urgent next job. The worker (M) comes to the workbench (P) to do the actual work (G).

The Workflow Process:

For a worker (M) to start working on a task (G), they must approach a workbench (P) and take a task from it.

The worker places the task's blueprint onto the workbench (curg) and begins working.
If the task needs to wait (for example, for materials to arrive — analogous to blocking on a channel), the worker puts the blueprint away in the desk drawer (g0 stack) and takes the next task from the workbench.
If the worker needs to step away for a very important reason (a system call), they leave the workbench (detach from the P) so that another worker can use it.
If the workbench runs out of tasks, the worker can approach a neighboring workbench and steal half of its tasks (work stealing).

Concurrency ≠ Parallelism

This is perhaps the most important statement by Rob Pike to understand.

Concurrency: This is about the composition of independently executing tasks. It's about structuring a program. Imagine you are cooking dinner: you put water on for pasta, you chop tomatoes for a salad, and you keep an eye on the patties in the pan. You are one person, but you are managing multiple tasks by switching between them. You are concurrent.
Parallelism: This is about the simultaneous execution of tasks. For this, you need multiple cooks (CPU cores). One cook boils the pasta, a second chops the salad, and a third fries the patties. They are working in parallel.

Go is built for concurrency first and foremost. It makes it easy to write programs structured as a set of interacting tasks. Whether this code actually executes in parallel depends on the hardware (the number of CPU cores) and the runtime settings (like GOMAXPROCS).

Characteristic	OS Threads	Go Goroutines
Stack Size	1-8 MB	2 KB (initial)
Creation	1000+ ns	~200 ns
Context Switch	1000+ ns	~200 ns
Management	OS Kernel	Go Runtime
Scalability	100-1000 threads	100,000+ goroutines

Scheduler Overhead:

Operation	Time (Go 1.20)
Goroutine Creation	~200 ns
Goroutine Context Switch	~200 ns
Blocking System Call	~500 ns
Network Operation (Non-blocking)	~100 ns

Goroutine Parking

The term "parking" in the context of the scheduler means that a running goroutine (G) is transitioned into a waiting state, and the OS thread (M) on which it was running is freed up to execute other goroutines. This is a key mechanism that prevents OS threads from idling when a goroutine blocks (e.g., waiting for data from a channel or for a system call to complete).

The process of "parking" and "unparking" is inextricably linked to the concepts of handoff and work stealing.

Scenarios for Goroutine Parking and M Behavior

Let's examine the main scenarios that clearly illustrate how M and G interact.

Blocking System Call (e.g., reading from a file) This is the classic case where a goroutine enters a long blocking call to the OS kernel.

Situation: Goroutine G1 is running on thread M1, which is attached to processor P1. G1 initiates a blocking system call (e.g., read(fileFd)).
Scheduler Action: The Go scheduler understands that M1 will be blocked by the kernel for an indeterminate amount of time. It detaches (handoff) P1 from M1. M1 goes into waiting for the system call to complete, along with G1.
Result: The now-freed P1 no longer has a thread. The scheduler takes another thread, for example, M2 (from a sleeping pool or creates a new one), and attaches it to P1. M2 begins executing the next goroutine G2 from P1's local run queue.
Return: When the system call in G1 completes, M1 wakes up. What should G1 do? It needs to run again. The scheduler looks for a free P. If there is a free P (e.g., P2), M1 with G1 attaches to it and continues working. If not, G1 is placed into the global run queue, and M1 becomes a spare (sleeping) thread.

Blocking on a Channel or Mutex Here, the blocking occurs not at the kernel level, but at the runtime level.

Situation: Goroutine G1 on M1 (with P1) attempts to read from a channel that has no data.
Action: The scheduler transitions G1 into a waiting state and places it into the wait queue of that channel. Important: M1 is no longer needed for this goroutine.
Result: M1 remains attached to P1 and immediately (in the same scheduler cycle) takes the next runnable goroutine G2 from P1's local queue and starts executing it. The OS thread does not idle for a nanosecond.
Return: When another goroutine sends data into the channel, G1 becomes "runnable". It will be added to the local queue of the P on which the sender goroutine is running (to improve data locality) or to the global run queue.

How the Scheduler Balances Load: Work Stealing

What happens when a thread has nothing to do? Imagine: on M1, attached to P1, all goroutines in the local queue are finished, and the global queue is empty. The scheduler will not let M1 simply go to sleep while others have work.

The work stealing mechanism is activated:

M1, in a "spinning" state (actively seeking work), selects another processor, for example, P2, and attempts to steal approximately half of the goroutines from its local run queue.
If successful, M1 begins executing the stolen goroutines. This way, the load is evenly distributed across all available OS threads.

The "Spinning Threads" Mechanism

When a thread (M) looks for work, as in the example above, it enters a spinning state. Spinning threads are not parked immediately; instead, they actively search for work for a short time (stealing, checking the global queue, the netpoller), consuming CPU resources in the process.

Why is this necessary? To avoid the frequent and expensive creation/destruction or parking/unparking of OS threads. The algorithm works like this:

When new work appears (a runnable goroutine), the scheduler checks if there are any idle P's and if there are already any spinning threads.
If there is an idle P and no spinning threads exist, the scheduler wakes up (unparks) a new OS thread (M) or creates one. This new thread enters spinning mode.
If spinning threads already exist, a new thread is not woken up — the existing ones will handle the work themselves.

This mechanism keeps exactly as many active threads as needed for maximum core utilization, without unnecessary context-switching overhead.

Locality and Affinity

The Go runtime tries, as much as possible, to keep a goroutine attached to the same thread. Why? This improves CPU cache locality. If a goroutine constantly jumps from thread to thread, its data must be constantly invalidated and reloaded into the cache of the new core, which is slow.

Thanks to the local queues on P and the work stealing mechanism, a goroutine that was blocked on a channel is highly likely to be resumed on the same P (and consequently, the same M) where it was previously running. The scheduler even gives priority to goroutines just unparked from channels, placing them at the front of the queue (runnext) so they execute as soon as possible and resume work with a "warm" cache.

Schematic Lifecycle

G is Running: G executes on M (which is attached to P).
G Blocks: G blocks (syscall, channel, mutex). The scheduler transitions G to Waiting.
- If syscall: M detaches from P, P looks for a new M. G remains on M.
- If channel/mutex: G enters the resource's wait queue. M stays with P and takes a new G from the local queue.
G becomes Runnable: The resource G was waiting for becomes available. The scheduler adds G to a queue (most often the local queue of the P that unblocked it).
G is Selected for Execution: When its turn comes, some M attached to this P will remove G from the queue and begin executing it.

Concurrency patterns on Golang: Singleflight

Silver_dev — Tue, 24 Feb 2026 17:42:33 +0000

Problems this pattern can solve:

The "Thundering Herd" problem. Imagine: a cache with user data has expired. 100 concurrent requests arrive, all see the cache miss and simultaneously stampede to the database. The database collapses under load, the service dies.
A microservice calls an external API with strict rate limits. Under high load, 10 parallel requests with the same key could exhaust the limit or simply create redundant traffic. (All requests with the same key are coalesced into a single external call, saving limits and resources.)
Heavy operations: web page parsing via a headless browser, generating PDF reports, ML inference. If 50 users request the same report, launching 50 browsers is memory suicide. (One browser will be launched, the result will be shared by all.)

Essence: Singleflight guarantees that for a given key, only one operation is executed at a time. All other calls with the same key do not start a new operation but "attach" themselves to the already running one and wait for its result. After the original call completes, all waiters receive the same result (or error).

Idea: Coalesce multiple concurrent requests with the same key into a single real call and distribute the result to all waiters.

Use the official package golang.org/x/sync/singleflight.

Singleflight vs Other Patterns

Difference from Caching.

Cache: Stores the result after execution. On concurrent access to an empty cache, all requests will still go to the DB (cache miss).
Singleflight: Doesn't store the result, but coalesces requests at the moment. After completion, the result is not saved (unless you put it in the cache yourself).

Difference from Semaphore (worker pool).

Semaphore: Limits the number of concurrently executing operations, but doesn't coalesce identical ones. 10 requests for the same key can execute in parallel (if the pool allows).
Singleflight: Regardless of pool size, only one operation is ever executed for a given key.

Difference from WaitGroup.

WaitGroup: Simply waits for a group of goroutines to complete, but doesn't manage duplicates or share results.
Singleflight: Uses WaitGroup internally to coordinate waiting goroutines and distribute the result.

Difference from Mutex.

Mutex: Locks access to a critical section, but each time the mutex is released, a new thread enters and repeats the operation.
Singleflight: The operation is executed once, the result is given to all.

Example

package main

import (
    "fmt"
    "sync"
    "time"

    "golang.org/x/sync/singleflight"
)

func main() {
    var group singleflight.Group
    var wg sync.WaitGroup

    key := "user:123"
    requests := 5

    // Simulating a heavy operation (database call or external API)
    expensiveOp := func() (interface{}, error) {
        fmt.Println("Heavy operation started (actually once)")
        time.Sleep(2 * time.Second) // simulating long work
        fmt.Println("Heavy operation completed")
        return "data_for_" + key, nil
    }

    // Launching 5 concurrent requests
    for i := 0; i < requests; i++ {
        wg.Add(1)
        go func(reqID int) {
            defer wg.Done()

            // Execute via singleflight
            result, err, shared := group.Do(key, expensiveOp)

            if err != nil {
                fmt.Printf("Request %d: error %v\n", reqID, err)
                return
            }
            fmt.Printf("Request %d: result = %v (shared = %v)\n",
                reqID, result, shared)
        }(i)
    }

    wg.Wait()
}

Concurrency patterns on Golang: ErrGroup

Silver_dev — Mon, 23 Feb 2026 22:48:18 +0000

Problems this pattern can solve:

You've launched 5 goroutines. You need to wait for all of them to complete, but if at least one fails with an error — stop the rest and return the error. Implementing this with sync.WaitGroup + context + error channels leads to boilerplate code that's easy to break.
In the classic approach, if one goroutine fails with an error, the rest continue working uselessly or, worse, block forever writing to a channel that no one is reading from. This is a resource leak.
The problem of complex error collection from multiple goroutines. You need to collect all errors or at least the first significant one. Manual implementation requires creating mutexes to protect a shared error variable or separate channels.

Essence: ErrGroup is a goroutine group manager that provides two main mechanisms:

Synchronization: Waiting for all launched goroutines to complete (like sync.WaitGroup).
Error propagation and cancellation: When an error occurs in any of the goroutines, the shared context is automatically canceled, signaling other goroutines to terminate, and the Wait() method returns this error.

Idea: Combine launching concurrent tasks, waiting for their completion, and automatically stopping all of them at the first error through a shared context.

Use the official package golang.org/x/sync/errgroup.

ErrGroup vs Other Patterns

Difference from sync.WaitGroup

sync.WaitGroup: A simple goroutine counter. Waits for all to complete, but doesn't handle errors and context. If a goroutine fails, the rest continue working.
ErrGroup: A wrapper over WaitGroup that adds context binding and "stop everything on first error" semantics.

Difference from Pipeline

Pipeline: A pattern for organizing sequential data processing stages, where data flows through channels.
ErrGroup: A pattern for managing concurrent tasks that may be independent or loosely coupled. Used for coordination, not for data stream transformation.

Difference from Worker Pool (Fan-out/Fan-in)

Worker Pool: About distributing tasks among a fixed number of workers for parallel processing.
ErrGroup: About coordinating the execution of a set of tasks (often heterogeneous) and reacting to the first error. ErrGroup can be used inside a worker or to manage a group of workers, but the focus is on cancellation, not task distribution.

Example

package main

import (
    "context"
    "fmt"
    "time"

    "golang.org/x/sync/errgroup"
)

func main() {
    // Create an errgroup with context
    g, ctx := errgroup.WithContext(context.Background())

    // Launch a goroutine that will complete successfully
    g.Go(func() error {
        select {
        case <-time.After(1 * time.Second):
            fmt.Println("Goroutine 1: success")
            return nil
        case <-ctx.Done():
            fmt.Println("Goroutine 1: canceled")
            return ctx.Err()
        }
    })

    // Launch a goroutine that will fail with an error
    g.Go(func() error {
        select {
        case <-time.After(500 * time.Millisecond):
            fmt.Println("Goroutine 2: error!")
            return fmt.Errorf("something went wrong in goroutine 2")
        case <-ctx.Done():
            fmt.Println("Goroutine 2: canceled")
            return ctx.Err()
        }
    })

    // Launch a goroutine that should be canceled
    g.Go(func() error {
        select {
        case <-time.After(3 * time.Second):
            fmt.Println("Goroutine 3: success (but this won't happen)")
            return nil
        case <-ctx.Done():
            fmt.Println("Goroutine 3: canceled")
            return ctx.Err() // context.Canceled
        }
    })

    // Wait for all goroutines to complete and get the first error
    if err := g.Wait(); err != nil {
        fmt.Printf("Error: %v\n", err)
    } else {
        fmt.Println("All successful")
    }

    // Give time to see the output
    time.Sleep(1 * time.Second)
}

Concurrency patterns on Golang: Fan-out / Fan-in

Silver_dev — Sun, 22 Feb 2026 20:40:08 +0000

Problems this pattern can solve:

You have 8 cores, but your data processing stage runs sequentially in a single goroutine. The CPU sits idle while the task queue grows. We create N workers (one per core) that pull tasks from a shared channel in parallel, utilizing all available cores.
Suppose your Pipeline has a stage that calls an external API or resizes images. This is slow. If left in a single thread, the entire pipeline will bottleneck at this stage.
You've launched 100 goroutines for web scraping. How do you collect all results in one place for final database writing, without using global variables and mutexes.
Creating a new goroutine for each incoming request is dangerous. Under peak load, this can crash the service (panic due to memory exhaustion).

Essence: A pattern consisting of two phases that work in tandem to parallelize tasks.
- Fan-out: The process of launching multiple goroutines (workers) to read tasks from a single input channel. This distributes the load.
- Fan-in: The process of merging results from multiple goroutines into a single output channel. This consolidates data for final processing.

Idea: Parallelize the execution of similar tasks by distributing them among a fixed pool of workers and subsequently aggregating results through multiplexing of output channels.

Fan-out / Fan-in vs Other Patterns

Difference from Pipeline

Fan-out/Fan-in: This is about horizontal scaling of a single stage. We take one step and multiply its executors.
Pipeline: This is about vertical decomposition of a process into different steps (read -> process -> write). Fan-out/Fan-in often lives inside one specific stage of a Pipeline.

Difference from Worker Pool

Actually, they are practically the same thing. Fan-out/Fan-in is a conceptual description of how a worker pool is structured.
Fan-out = task dispatching to the pool. Fan-in = result collection from the pool.
You could say that Fan-out/Fan-in is an architectural pattern, and Worker Pool is its concrete implementation for executing tasks.

Difference from Pub/Sub (Publish-Subscribe)

Fan-out/Fan-in: Each task from the input channel is received by only one worker. This is work distribution (competition for tasks).
Pub/Sub: Each message is received by all subscribers. This is broadcast distribution.

Example

package main

import (
    "context"
    "fmt"
    "sync"
)

// Task generation
func generateJobs(n int) <-chan int {
    ch := make(chan int)
    go func() {
        for i := 1; i <= n; i++ {
            ch <- i
        }
        close(ch)
    }()
    return ch
}

// Fan-out: Distributing tasks among workers
func fanOut(ctx context.Context, jobs <-chan int, numWorkers int) []<-chan int {
    workerChannels := make([]<-chan int, 0, numWorkers)

    for i := 0; i < numWorkers; i++ {
        resultCh := make(chan int)

        go func() {
            defer close(resultCh)
            for {
                select {
                case job, ok := <-jobs:
                    if !ok {
                        return // Task channel closed
                    }
                    // Task processing (example: squaring)
                    resultCh <- job * job
                case <-ctx.Done():
                    return // Cancellation via context
                }
            }
        }()

        workerChannels = append(workerChannels, resultCh)
    }
    return workerChannels
}

// Fan-in: Merging results
func fanIn(channels []<-chan int) <-chan int {
    var wg sync.WaitGroup
    merged := make(chan int)

    wg.Add(len(channels))

    for _, ch := range channels {
        go func(c <-chan int) {
            defer wg.Done()
            for res := range c {
                merged <- res
            }
        }(ch)
    }

    // Goroutine to close the final channel
    go func() {
        wg.Wait()
        close(merged)
    }()

    return merged
}

func main() {
    // 1. Generate tasks
    jobs := generateJobs(5)

    // 2. Fan-out: distribute tasks among 3 workers
    resultChannels := fanOut(context.Background(), jobs, 3)

    // 3. Fan-in: merge results from all channels
    mergedResults := fanIn(resultChannels)

    // 4. Results
    for res := range mergedResults {
        fmt.Printf("Получен результат: %d\n", res)
    }
}

Concurrency patterns on Golang: Pipeline

Silver_dev — Sun, 22 Feb 2026 18:26:11 +0000

Problems this pattern can solve:

When you need to process millions of records (e.g., log lines, images, or database entries), executing all steps sequentially for one item after another leads to resource underutilization. The CPU sits idle during I/O operations (disk reads, network requests), while subsequent steps wait for previous ones to complete.
Imagine a 500-line function that does: read -> transform -> validate -> enrich -> save. It's impossible to cover with adequate tests, difficult to extend (adding a new step requires modifying the entire function), and easy to break by affecting the logic of an adjacent step.
In concurrent environments, it's challenging to properly handle situations where a fatal error occurs at one stage. You need to stop all stages, prevent goroutine leaks, and shut down the program gracefully.

Essence: Breaking down a complex data processing operation into a sequence of independent, reusable stages, where each stage performs one specific function, and data is passed between them via channels.

Idea: Split data processing into sequential, concurrently executing stages, where the output of one stage serves as input for the next, using channels as a conveyor belt for data transfer and flow control.

Pipeline vs Other Patterns

Difference from Chain of Responsibility

Pipeline: Each element necessarily goes through all stages of the pipeline and is transformed at each stage. Data moves in one direction. It's about data processing.
Chain of Responsibility: A request is passed along a chain of handlers until one of them handles it. The request does not necessarily go through the entire chain. It's about passing responsibility. (Example: middleware in web frameworks, where one handler can return a response and break the chain).

Difference from Fan-Out / Fan-In

Pipeline: This is a structural code organization pattern.
Fan-Out / Fan-In: These are parallelization patterns often used inside Pipeline stages.
- Fan-Out: Launching multiple goroutines (workers) at one stage to parallelize heavy work.
- Fan-In: Collecting results from multiple workers back into a single channel.
- It can be said that Fan-Out/Fan-In are ways to implement a specific Pipeline stage to improve performance.

Difference from Observer

Pipeline: Push-model. The "generator" actively sends data to the next stage. It's a unidirectional stream.
Observer: One subject notifies many subscribers about changes in its state (one-to-many). Subscribers are passive and wait for notifications. It's about event broadcasting, not data transformation.

Example

package main

import "fmt"

// stage 1: Generator
func gen(nums ...int) <-chan int {
    out := make(chan int)
    go func() {
        for _, n := range nums {
            out <- n
        }
        close(out)
    }()
    return out
}

// stage 2: Multiplying by 2
func sq(in <-chan int) <-chan int {
    out := make(chan int)
    go func() {
        for n := range in {
            out <- n * n
        }
        close(out)
    }()
    return out
}

func main() {
    // Assembling the pipeline
    in := gen(2, 3, 4)
    out := sq(in)

    // Result
    for result := range out {
        fmt.Println(result) // 4, 9, 16
    }
}

Concurrency patterns on Golang: Semaphore

Silver_dev — Sat, 21 Feb 2026 21:50:00 +0000

Problems this pattern can solve:

The external API only allows 5 concurrent requests. Any more — and it bans by IP.
You have a database connection pool of 10. If you spawn 100 goroutines, each will try to acquire a connection — 90 will be waiting and consuming memory.
A microservice collapses under load. You need to limit the number of concurrent requests to it, and when the limit is exceeded — quickly return an error without overloading the service.

Essence: A synchronization mechanism that uses a counter to limit the number of concurrently executing operations or access to a resource. Goroutines "acquire" the semaphore before starting work and "release" it upon completion, while the semaphore blocks new acquisitions when the counter reaches zero.

Key idea: A permission counter that blocks execution when the limit is exhausted and allows it when there are free slots.

Use the official package golang.org/x/sync/semaphore except when you need a combination with other channel-based patterns or require specific behavior.

Example (Simplified)

// Semaphore = buffered channel with empty structs
sem := make(chan struct{}, N)

sem <- struct{}{} // Acquire: take a permit (blocks if full)
<-sem             // Release: return a permit

Semaphore Disadvantages:

No priorities. Semaphore does not guarantee access order (FIFO)
Deadlock risk. Careful defer required.
No ownership. Unlike a mutex, a semaphore can be released by any goroutine, not only the one that acquired it.

Semaphore vs Other Patterns:

Worker Pool

Worker Pool: Manages goroutines that execute tasks. Workers live permanently.
Semaphore: Manages access to a resource. Goroutines are created per task but are blocked by the semaphore before the "heavy" operation.
Key difference: Semaphore does not create goroutines, it only limits their concurrent execution.

Mutex (sync.Mutex)

Mutex: Binary (0 or 1), protects a critical section from simultaneous access.
Semaphore: Can be counting (N > 1), manages the number of concurrent accesses.
Key difference: Mutex is for mutual exclusion, semaphore is for limiting concurrency.

Rate Limiter

Rate Limiter: Limits the number of operations per time unit (e.g., 100/sec).
Semaphore: Limits the number of concurrent operations (e.g., 10 concurrent requests).
Key difference: Rate limiter works with a time window, semaphore works with concurrency.

Channels

Channels: Pass data between goroutines, can be used as semaphores.
Semaphore: Specialized primitive for synchronization only, without data passing.
Key difference: Semaphore is lighter and faster for pure access limiting.

Example

package main

import (
    "fmt"
    "sync"
    "time"
)

// Semaphore - concurrency limiter
type Semaphore struct {
    ch chan struct{}
}

func NewSemaphore(maxConcurrent int) *Semaphore {
    return &Semaphore{
        ch: make(chan struct{}, maxConcurrent),
    }
}

// Acquire - get a permit (blocks if limit is exceeded)
func (s *Semaphore) Acquire() {
    s.ch <- struct{}{} // Send blocks when channel is full
}

// Release - return permit to the pool
func (s *Semaphore) Release() {
    <-s.ch // Release slot
}

func worker(id int, sem *Semaphore, wg *sync.WaitGroup) {
    defer wg.Done()

    sem.Acquire()       // Wait for free slot
    defer sem.Release() // Release after work

    fmt.Printf("[%s] Worker %d: started work\n", time.Now().Format("15:04:05"), id)
    time.Sleep(2 * time.Second) // Simulate work
    fmt.Printf("[%s] Worker %d: finished\n", time.Now().Format("15:04:05"), id)
}

func main() {
    sem := NewSemaphore(3) // Maximum 3 concurrent tasks
    var wg sync.WaitGroup

    // Start 10 goroutines, but only 3 will be active
    for i := 1; i <= 10; i++ {
        wg.Add(1)
        go worker(i, sem, &wg)
        time.Sleep(200 * time.Millisecond) // Small delay between launches
    }

    wg.Wait()
    fmt.Println("All tasks completed")
}

Concurrency patterns on Golang: Worker Pool

Silver_dev — Thu, 19 Feb 2026 20:52:44 +0000

Problems this pattern can solve:

If your service makes 1,000 queries per second to a database, but it can only handle 100, a worker pool will protect the database from crashing.
In the event of a sudden traffic spike, using go func() for each request could spawn 100,500 goroutines and consume all your memory. The pool limits concurrency.
If you have a pool of socket connections or file descriptors, a worker pool ensures you don't exceed the OS limit.

The Essence:
We create a fixed number of goroutines (workers) that are started in advance and wait for tasks. The main goroutine (the dispatcher) puts tasks into a channel (the task queue). The workers concurrently take these tasks from the channel and execute them. They can send the results back through another channel.

The Idea: Limiting the number of concurrently executed operations and reusing goroutines.

Difference between Worker Pool and other approaches:

go func() (Spawning raw goroutines):

Cons compared to Worker Pool: Uncontrolled growth in the number of goroutines can lead to resource exhaustion (memory, file descriptors) and a panic. There is no control over concurrency.
Pros compared to Worker Pool: Simpler to write, lower startup latency (no need to wait for a free worker).
When to use it: For handling signals, very lightweight tasks, or when the load is guaranteed to be low.

Pipeline:

How it's different: This is about sequential processing. Data flows through a chain of stages, where each stage is executed by its own goroutine (or pool), connected by channels.
Example: stage1 (generate) -> stage2 (multiply) -> stage3 (save)
Cons compared to Worker Pool: More difficult to cancel and handle errors; the throughput is limited by the slowest stage.
Pros compared to Worker Pool: Ideal for tasks that can be broken down into distinct, independent processing steps.

Semaphore:

How it's different: A semaphore is a synchronization primitive used to limit access to a resource. You still spawn a goroutine for each task, but before starting the "heavy" part, they acquire a slot from the semaphore.
How this relates: A Worker Pool is often implemented using a semaphore, but a semaphore is a lower-level tool.
If the task is heavy (e.g., an HTTP request, complex calculation, disk I/O) and there aren't millions of them — use a Semaphore. The overhead of creating a goroutine is negligible compared to the task's execution time (e.g., parallel scraping of 50 websites).
If the task is very light (e.g., parsing a string, a simple transformation) and the stream is infinite — use a Worker Pool. Otherwise, the GC will be overwhelmed by the creation of thousands of goroutines (e.g., real-time log processing, handling events from Kafka).

MapReduce:

How it's different: A higher-level pattern for distributed computations. It involves a "Map" phase (parallelization) and a "Reduce" phase (aggregation). A Worker Pool is often used as an implementation for the "Map" phase.
Cons compared to Worker Pool: Overkill for simple concurrent processing.

Example:

package main

import (
    "fmt"
    "sync"
    "time"
)

func worker(id int, wg *sync.WaitGroup, jobs <-chan int) {
    defer wg.Done()
    defer func() {
        if r := recover(); r != nil {
            fmt.Printf("Worker %d: panic: %v\n", id, r)
        }
    }()

    for job := range jobs {
        fmt.Printf("Worker %d started the task %d\n", id, job)
        time.Sleep(time.Second) // Simulating a task
        fmt.Printf("Worker %d completed the task %d\n", id, job)
    }
}

func main() {
    const numJobs = 10
    const numWorkers = 3
    jobs := make(chan int, numJobs)
    var wg sync.WaitGroup

    for w := 1; w <= numWorkers; w++ {
        wg.Add(1)
        go worker(w, &wg, jobs)
    }

    for j := 1; j <= numJobs; j++ {
        jobs <- j
    }
    close(jobs)
    wg.Wait()
    fmt.Println("All tasks completed")
}