Mastering Go Concurrency: Goroutines, Scheduler, and Safe Data Sharing

Using Goroutine to Run Programs

1. Go concurrency and parallelism

Go's concurrency allows a function to run independently as a goroutine, scheduled by the runtime onto logical processors (P) bound to OS threads (M). The scheduler manages goroutine execution, runqueues, and can bind P to different M when a thread blocks.

Manages all created goroutines and allocates execution time

Binds OS threads to logical processors

The scheduler uses three entities: M (OS thread), P (logical processor), G (goroutine). Each P has a global runqueue of ready goroutines. When go func launches a goroutine, it is appended to the runqueue; the scheduler later picks a goroutine to run.

When an OS thread M blocks, the scheduler can bind the P to another M, ensuring other goroutines continue. The default limit is 10,000 threads, adjustable via runtime/debug.SetMaxThreads.

Concurrency runs on a single logical processor; parallelism requires multiple logical processors. The scheduler distributes goroutines across them.

2. Creating goroutine

Use the go keyword to start a goroutine. Example code demonstrates creating two goroutines that print alphabet letters, using runtime.GOMAXPROCS(1) to allocate one logical processor.

package main

import (
    "runtime"
    "sync"
    "fmt"
)

var wg sync.WaitGroup

func main() {
    // allocate one logical processor
    runtime.GOMAXPROCS(1)
    wg.Add(2)
    fmt.Printf("Begin Coroutines
")
    go func() {
        defer wg.Done()
        for count := 0; count < 3; count++ {
            for char := 'a'; char < 'a'+26; char++ {
                fmt.Printf("%c ", char)
            }
        }
    }()
    go func() {
        defer wg.Done()
        for count := 0; count < 3; count++ {
            for char := 'A'; char < 'A'+26; char++ {
                fmt.Printf("%c ", char)
            }
        }
    }()
    fmt.Printf("Waiting To Finish
")
    wg.Wait()
}

Running with one processor prints all uppercase letters then lowercase. To achieve parallel execution, set runtime.GOMAXPROCS(2). runtime.GOMAXPROCS(2) With two processors the output interleaves letters.

When only one processor is available, goroutines can be forced to yield using runtime.Gosched(). Example shows yielding at specific characters.

package main

import (
    "runtime"
    "sync"
    "fmt"
)

var wg sync.WaitGroup

func main() {
    runtime.GOMAXPROCS(1)
    wg.Add(2)
    fmt.Printf("Begin Coroutines
")
    go func() {
        defer wg.Done()
        for count := 0; count < 3; count++ {
            for char := 'a'; char < 'a'+26; char++ {
                if char == 'k' {
                    runtime.Gosched()
                }
                fmt.Printf("%c ", char)
            }
        }
    }()
    go func() {
        defer wg.Done()
        for count := 0; count < 3; count++ {
            for char := 'A'; char < 'A'+26; char++ {
                if char == 'K' {
                    runtime.Gosched()
                }
                fmt.Printf("%c ", char)
            }
        }
    }()
    fmt.Printf("Waiting To Finish
")
    wg.Wait()
}

2. Handling Race Conditions

Concurrent goroutines accessing shared resources can cause race conditions. Go provides tools like the -race flag to detect races.

go build -race example4.go ./example4

The race detector points out conflicting lines in the source code.

1. Detecting race conditions

Use atomic functions, mutexes, or channels to synchronize access.

2. Using atomic functions

Atomic operations ensure safe increment of a counter.

package main

import (
    "sync"
    "runtime"
    "fmt"
    "sync/atomic"
)

var (
    counter int64
    wg      sync.WaitGroup
)

func addCount() {
    defer wg.Done()
    for count := 0; count < 2; count++ {
        atomic.AddInt64(&counter, 1)
        runtime.Gosched()
    }
}

func main() {
    wg.Add(2)
    go addCount()
    go addCount()
    wg.Wait()
    fmt.Printf("counter: %d
", counter)
}

Atomic functions such as atomic.AddInt64, atomic.StoreInt64, and atomic.LoadInt64 are provided by the sync/atomic package.

3. Using mutex

Mutex locks define critical sections, ensuring only one goroutine modifies the shared variable at a time.

package main

import (
    "sync"
    "runtime"
    "fmt"
)

var (
    counter int
    wg      sync.WaitGroup
    mutex   sync.Mutex
)

func addCount() {
    defer wg.Done()
    for count := 0; count < 2; count++ {
        mutex.Lock()
        value := counter
        runtime.Gosched()
        value++
        counter = value
        mutex.Unlock()
    }
}

func main() {
    wg.Add(2)
    go addCount()
    go addCount()
    wg.Wait()
    fmt.Printf("counter: %d
", counter)
}

3. Sharing Data with Channels

Go follows the CSP model; channels enable communication between goroutines without explicit locks. Channels are created with make and can be buffered or unbuffered.

unbuffered := make(chan int) // unbuffered channel for int
buffered := make(chan string, 10) // buffered channel for string
buffered <- "hello world"
value := <-buffered

Unbuffered channels synchronize send and receive; buffered channels allow storing values until they are consumed.

1. Unbuffered channels

Example simulates a tennis match using an unbuffered channel.

package main

import (
    "sync"
    "fmt"
    "math/rand"
    "time"
)

var wg sync.WaitGroup

func player(name string, court chan int) {
    defer wg.Done()
    for {
        ball, ok := <-court
        if !ok {
            fmt.Printf("Player %s Won
", name)
            return
        }
        n := rand.Intn(100)
        if n%13 == 0 {
            fmt.Printf("Player %s Missed
", name)
            close(court)
            return
        }
        fmt.Printf("Player %s Hit %d
", name, ball)
        ball++
        court <- ball
    }
}

func main() {
    rand.Seed(time.Now().Unix())
    court := make(chan int)
    wg.Add(2)
    go player("candy", court)
    go player("luffic", court)
    court <- 1
    wg.Wait()
}

2. Buffered channels

Buffered channels block only when full (on send) or empty (on receive). Sending to a closed channel panics; receivers can still read remaining values. The sender should close the channel.

Summary

Goroutine execution is managed by logical processors and runqueues.

Multiple goroutines can run concurrently; parallelism needs multiple logical processors.

Use the go keyword to create a goroutine.

Race conditions arise from unsynchronized access to shared resources.

Mutexes or atomic functions prevent race conditions.

Channels provide a safer way to share data between goroutines.

Unbuffered channels are synchronous; buffered channels are asynchronous.