Golang Concurrency: How Confinement Improves Performance Without Locks

Concurrency is one of Go's greatest strengths, but it can also be a source of many problems if you're not careful or don't fully understand what you're doing. Is writing concurrent code difficult? I'd say it's one of the challenging parts in programming because so many things can go wrong. Go makes it easier with Goroutines compared to other languages, but that doesn't mean it's foolproof. One way to avoid going the wrong way with concurrency is to use tha patterns that has been already tested overtime instead of trying to invent your own. In this blog we will learn how you can utilize confinement pattern to improve your Go concurrency performance. What's confinement? Confinement is a simple yet powerful pattern that ensures data is only accessible from a single concurrent process. When done correctly, it makes a concurrent program completely safe, eliminating the need for synchronization. In Go, the confinement pattern keeps data access and modifications restricted to a single Goroutine. This approach helps avoid race conditions and ensures safe operations without relying on synchronization tools like mutexes. Imagine a writer keeping notes in a private journal. Since only they write and read from it, there's no risk of conflicting edits or needing coordination with others. Similarly, in Go, if a single goroutine owns and modifies a piece of data, there's no need for synchronization mechanisms like mutexes, since no other goroutine can interfere with it. Why Use Confinement? Avoid race conditions without using mutexes. Improve performance by eliminating locking overhead. Simplify code by keeping state management within a single goroutine. That being said nothing explains it better than some code examples. Code Examples Example 1: Race condition and no confinement The code simulates processing multiple orders concurrently by spawning a goroutine for each order, which appends the processed result to a shared slice. However, since all goroutines access and modify the slice simultaneously without synchronization, a race condition occurs, leading to unpredictable results. package main import ( "fmt" "strings" "sync" ) func processOrder(order string) string { return fmt.Sprintf("Processed %s", order) } func addOrder(order string, result []string, wg sync.WaitGroup) { processedOrder := processOrder(order) result = append(result, processedOrder) // Shared state modified by multiple goroutines (critical section) wg.Done() } func main() { var wg sync.WaitGroup orders := []string{"Burger", "Pizza", "Pasta"} processedOrders := make([]string, 0, len(orders)) for _, order := range orders { wg.Add(1) go addOrder(order, &processedOrders, &wg) } wg.Wait() fmt.Println("Processed Orders:", strings.Join(processedOrders, ", ")) }

Feb 24, 2025 - 16:14

Golang Concurrency: How Confinement Improves Performance Without Locks

Concurrency is one of Go's greatest strengths, but it can also be a source of many problems if you're not careful or don't fully understand what you're doing.

Is writing concurrent code difficult? I'd say it's one of the challenging parts in programming because so many things can go wrong. Go makes it easier with Goroutines compared to other languages, but that doesn't mean it's foolproof.

One way to avoid going the wrong way with concurrency is to use tha patterns that has been already tested overtime instead of trying to invent your own.

In this blog we will learn how you can utilize confinement pattern to improve your Go concurrency performance.

What's confinement?

Confinement is a simple yet powerful pattern that ensures data is only accessible from a single concurrent process. When done correctly, it makes a concurrent program completely safe, eliminating the need for synchronization.

In Go, the confinement pattern keeps data access and modifications restricted to a single Goroutine. This approach helps avoid race conditions and ensures safe operations without relying on synchronization tools like mutexes.

Imagine a writer keeping notes in a private journal. Since only they write and read from it, there's no risk of conflicting edits or needing coordination with others.

Similarly, in Go, if a single goroutine owns and modifies a piece of data, there's no need for synchronization mechanisms like mutexes, since no other goroutine can interfere with it.

Why Use Confinement?

Avoid race conditions without using mutexes.
Improve performance by eliminating locking overhead.
Simplify code by keeping state management within a single goroutine.

That being said nothing explains it better than some code examples.

Code Examples

Example 1: Race condition and no confinement

The code simulates processing multiple orders concurrently by spawning a goroutine for each order, which appends the processed result to a shared slice. However, since all goroutines access and modify the slice simultaneously without synchronization, a race condition occurs, leading to unpredictable results.

package main

import (
    "fmt"
    "strings"
    "sync"
)

func processOrder(order string) string {
    return fmt.Sprintf("Processed %s", order)
}

func addOrder(order string, result *[]string, wg *sync.WaitGroup) {
    processedOrder := processOrder(order)
    *result = append(*result, processedOrder) // Shared state modified by multiple goroutines (critical section)
    wg.Done()
}

func main() {
    var wg sync.WaitGroup

    orders := []string{"Burger", "Pizza", "Pasta"}
    processedOrders := make([]string, 0, len(orders))

    for _, order := range orders {
        wg.Add(1)

        go addOrder(order, &processedOrders, &wg)
    }

    wg.Wait()

    fmt.Println("Processed Orders:", strings.Join(processedOrders, ", "))
}