Exercises — Module 17: Runtime Internals and the Memory Model¶

Work through exercises in order — they're designed to build on each other. Attempt each problem genuinely before looking at the solution. Seeing the solution first might feel like progress, but it isn't.

Instructions¶

1. Attempt first. Spend at least the estimated time on each problem before checking hints or solutions.
2. Write your work. Don't just run code mentally — actually write or type your attempt.
3. Check your answer against the acceptance criteria, not just the solution code.
4. Score yourself honestly in the Scoring Log at the bottom.
5. If you're stuck after a genuine effort, use the hints one at a time — not all at once.

Difficulty Legend¶

Exercise 1: G-M-P Vocabulary [🟢 Easy] [1 pt]¶

Context¶

The G-M-P model is the foundation of the Go scheduler. Before reasoning about scheduler behavior, you need to be precise about what each entity is and what constraints govern them.

Task¶

Without running any code, write a short explanation (4–6 sentences) answering all of the following: 1. What is a G (goroutine), and what state does it carry? 2. What is an M (machine), and what is its relationship to OS threads? 3. What is a P (processor), and why is the number of P's (not M's) the key limit on Go-code parallelism? 4. What does GOMAXPROCS control, and what is its default value?

Requirements¶

• Correctly describes G, M, and P as distinct entities
• Explains why P is the bottleneck for CPU-bound parallelism (not M)
• States the default value of GOMAXPROCS
• No code required — this is a written explanation

Hints¶

Solution¶

Exercise 2: GOMAXPROCS and Scheduler Observation [🟡 Medium] [2 pts]¶

Context¶

Understanding GOMAXPROCS requires observation, not just memorization. This exercise measures the effect of GOMAXPROCS on CPU-bound parallel work and requires you to reason about why the speedup behaves the way it does.

Task¶

Write a Go program that: 1. Defines a CPU-bound function work(n int) that iterates a loop n times doing arithmetic (no I/O, no channel ops) 2. Runs the function in parallel across 8 goroutines, measuring total wall-clock time, first with GOMAXPROCS=1, then with GOMAXPROCS=runtime.NumCPU() 3. Prints both durations and the speedup ratio

Then, in a comment above main, answer: "What speedup would you expect, and why does it not perfectly equal NumCPU()?"

Requirements¶

• Uses sync.WaitGroup to wait for all 8 goroutines
• Calls runtime.GOMAXPROCS(1) before the first measurement and runtime.GOMAXPROCS(runtime.NumCPU()) before the second
• Prints both durations and a speedup ratio
• Includes a comment explaining the expected speedup and its limitations

Hints¶

Solution¶

// Expected speedup: close to NumCPU() for pure CPU-bound work with enough goroutines,
// but not exactly NumCPU() due to:
// 1. Scheduling overhead (P hand-off, context switching between goroutines)
// 2. Cache contention (multiple cores evicting each other's cache lines)
// 3. WaitGroup synchronization overhead
// 4. The OS may not schedule all M's on separate physical cores simultaneously
// On machines with hyperthreading, speedup may plateau below NumCPU() because
// hyperthreads share the same physical core's execution units.
package main

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

func work(n int) {
    // Pure CPU work: no I/O, no channel ops, no allocations
    sum := 0
    for i := 0; i < n; i++ {
        sum += i * i
    }
    _ = sum // prevent compiler from eliminating the loop
}

func measureParallel(procs, goroutines, iterations int) time.Duration {
    runtime.GOMAXPROCS(procs)
    var wg sync.WaitGroup
    start := time.Now()
    for i := 0; i < goroutines; i++ {
        wg.Add(1)
        go func() {
            defer wg.Done()
            work(iterations)
        }()
    }
    wg.Wait()
    return time.Since(start)
}

func main() {
    ncpu := runtime.NumCPU()
    const goroutines = 8
    const iterations = 20_000_000

    d1 := measureParallel(1, goroutines, iterations)
    dN := measureParallel(ncpu, goroutines, iterations)

    speedup := float64(d1) / float64(dN)
    fmt.Printf("GOMAXPROCS=1:       %v\n", d1)
    fmt.Printf("GOMAXPROCS=%d:      %v\n", ncpu, dN)
    fmt.Printf("Speedup:            %.2fx (theoretical max: %dx)\n", speedup, ncpu)
}

Exercise 3: Happens-Before Reasoning [🔴 Hard] [3 pts]¶

Context¶

The Go Memory Model defines happens-before as the only guarantee of visibility. This exercise requires you to analyze three code snippets and determine for each: is it correctly synchronized, does it contain a data race, and which specific happens-before rule (if any) applies?

Task¶

For each of the following three snippets, write a brief analysis (2–4 sentences each): - Is there a data race? (Yes/No) - If no: which happens-before relationship makes it safe? - If yes: what synchronization primitive would fix it?

Snippet A:

var x int
ch := make(chan int, 1) // buffered, capacity 1
go func() {
    x = 42
    ch <- 1
}()
<-ch
fmt.Println(x)

Snippet B:

var x int
var once sync.Once
go func() {
    once.Do(func() { x = 42 })
}()
once.Do(func() {}) // no-op; ensures once has been called
fmt.Println(x)

Snippet C:

var x int
var wg sync.WaitGroup
wg.Add(1)
go func() {
    x = 42
    wg.Done()
}()
// No wg.Wait() — main just reads x after a time.Sleep(time.Millisecond)
time.Sleep(time.Millisecond)
fmt.Println(x)

Requirements¶

• Correctly classifies each snippet as safe or racy
• For safe snippets: names the specific happens-before rule from the Go Memory Model
• For racy snippets: proposes the minimal fix
• Does not rely on "it will probably work" reasoning — only formal happens-before guarantees

Hints¶

Solution¶

Exercise 4: Data-Race Analysis [🔴 Hard] [3 pts]¶

Context¶

Identifying data races requires recognizing not just "is there a mutex?" but "does the synchronization establish happens-before for these specific memory accesses?" This exercise presents a realistic concurrent pattern with a subtle race.

Task¶

Analyze the following program. It is supposed to be a simple concurrent cache. Identify: 1. Does it have a data race? If yes, on which variable(s) and between which operations? 2. What would the race detector output look like (describe it, don't run it)? 3. Fix the race with the minimal change that maintains the concurrent-read property.

package main

import (
    "fmt"
    "sync"
)

type Cache struct {
    mu    sync.Mutex
    store map[string]string
}

func (c *Cache) Set(key, val string) {
    c.mu.Lock()
    c.store[key] = val
    c.mu.Unlock()
}

func (c *Cache) Get(key string) (string, bool) {
    // Intentional optimization attempt: skip the lock for reads
    val, ok := c.store[key] // QUESTION: is this safe?
    return val, ok
}

func main() {
    cache := &Cache{store: make(map[string]string)}
    var wg sync.WaitGroup

    for i := 0; i < 100; i++ {
        wg.Add(2)
        go func(n int) {
            defer wg.Done()
            cache.Set(fmt.Sprintf("key%d", n), "value")
        }(i)
        go func(n int) {
            defer wg.Done()
            cache.Get(fmt.Sprintf("key%d", n))
        }(i)
    }
    wg.Wait()
}

Requirements¶

• Correctly identifies the data race (on the map)
• Explains why reading a map without a lock races with concurrent writes
• Proposes a fix — either sync.RWMutex for concurrent-safe reads, or a sync.Map
• Explains why RLock/RUnlock preserves concurrent read performance better than a plain Mutex

Hints¶

Solution¶

DATA RACE
Read at 0x... by goroutine N:
  main.(*Cache).Get(...)
      .../main.go:20
Previous write at 0x... by goroutine M:
  main.(*Cache).Set(...)
      .../main.go:14

type Cache struct {
    mu    sync.RWMutex  // changed from sync.Mutex
    store map[string]string
}

func (c *Cache) Set(key, val string) {
    c.mu.Lock()         // exclusive write lock
    c.store[key] = val
    c.mu.Unlock()
}

func (c *Cache) Get(key string) (string, bool) {
    c.mu.RLock()        // shared read lock — multiple Readers can hold this simultaneously
    val, ok := c.store[key]
    c.mu.RUnlock()
    return val, ok
}

Exercise 5: GC Knobs and Tradeoffs [🟡 Medium] [2 pts]¶

Context¶

GOGC and GOMEMLIMIT are the two primary knobs for GC behavior. Understanding their interaction and tradeoffs lets you make informed tuning decisions for production workloads.

Task¶

Without writing a full program, answer the following in clear prose: 1. You have a batch data-processing job that allocates a lot of intermediate data and does not care about latency — it just needs to complete as fast as possible. Which GOGC setting would you choose (higher, lower, or off)? Why? 2. You have a container-hosted microservice limited to 512 MiB of memory. The service's live heap is typically ~100 MiB. What combination of GOGC and GOMEMLIMIT would you set? Why? 3. A colleague suggests setting GOGC=off permanently in the microservice to eliminate GC pauses. What is wrong with this suggestion?

Requirements¶

• Correctly recommends high GOGC or GOGC=off for the batch job with a reason
• Correctly uses GOMEMLIMIT as the safety ceiling for the container case
• Identifies the flaw in GOGC=off for a long-running service (unbounded memory growth)

Hints¶

Solution¶

debug.SetGCPercent(200)          // allow heap to grow to 3× live before GC → ~300 MB
debug.SetMemoryLimit(460 << 20)  // 460 MiB ceiling (~90% of 512 MiB)

Exercise 6: unsafe.Pointer Rules Quiz [🟢 Easy] [1 pt]¶

Context¶

unsafe.Pointer has six documented rules in the Go spec. Knowing which operations are legal prevents crashes and GC-visible corruption.

Task¶

For each code snippet below, state whether it is VALID or INVALID under the unsafe.Pointer rules, and give a one-sentence reason.

// A: type-punning
var f float64 = 3.14
bits := *(*uint64)(unsafe.Pointer(&f))

// B: storing uintptr
var x int = 42
addr := uintptr(unsafe.Pointer(&x))
doWork() // may trigger GC or stack copy
y := *(*int)(unsafe.Pointer(addr))

// C: pointer arithmetic with unsafe.Add
s := []byte{1, 2, 3, 4}
p := unsafe.Pointer(&s[0])
third := *(*byte)(unsafe.Add(p, 2))

// D: converting uintptr back in same expression
var arr [4]int
p2 := (*int)(unsafe.Pointer(uintptr(unsafe.Pointer(&arr[0])) + unsafe.Sizeof(arr[0])))

Solution¶

Exercise 7: cgo Cost Analysis [⭐ Challenge] [5 pts]¶

Context¶

cgo enables Go programs to call C, but at real costs: call overhead, scheduler interaction, build complexity, and loss of cross-compilation. This challenge requires writing a micro-benchmark, observing the cost, and writing a recommendation memo.

Task¶

1. Write a Go program that benchmarks cgo call overhead vs. Go function call overhead. Define a trivial C function int noop(int x) { return x; } and a trivially equivalent Go function func noopGo(x int) int { return x }. Benchmark both using testing.B (or a manual loop with time.Now). Aim for 10 million calls per measurement.

2. Below the benchmark code, write a short "when to use cgo" decision framework as a comment block. Address: (a) minimum performance bar before adding cgo, (b) build/CI requirements cgo imposes, © one scenario where cgo is clearly worth it and one where it clearly is not.

Requirements¶

• Implements a /*int noop(int x) { return x; }*/ import "C" C function and a Go equivalent
• Measures both with a comparable loop count and prints the per-call cost for each
• Comments include a "when to use cgo" framework covering overhead, build requirements, and a clear yes/no example
• Output shows a significant overhead ratio (expect ~10–50× difference)

Hints¶

const N = 10_000_000
start := time.Now()
for i := 0; i < N; i++ {
    C.noop(C.int(i))
}
cgoDuration := time.Since(start)
// repeat for noopGo

Solution¶

package main

/*
// A trivial C function to measure cgo call overhead
int noop_c(int x) { return x; }
*/
import "C"

import (
    "fmt"
    "time"
)

// Go equivalent — should be inlined by the compiler
func noopGo(x int) int { return x }

const N = 10_000_000

func benchCgo() time.Duration {
    start := time.Now()
    for i := 0; i < N; i++ {
        _ = C.noop_c(C.int(i))
    }
    return time.Since(start)
}

func benchGo() time.Duration {
    start := time.Now()
    for i := 0; i < N; i++ {
        _ = noopGo(i)
    }
    return time.Since(start)
}

// When to use cgo — decision framework:
//
// OVERHEAD: A cgo call costs ~100–200 ns on modern hardware (vs ~1–5 ns for a
// pure Go call). This means any C function called > ~5,000 times/sec adds
// measurable overhead. Before adding cgo, benchmark your hot path.
//
// BUILD REQUIREMENTS: cgo requires a C toolchain (gcc/clang) on every build
// machine, including CI. It disables cross-compilation unless you configure
// a cross-compiling C toolchain. Docker-based cross-compilation becomes
// significantly more complex. Set CGO_ENABLED=0 to verify your code compiles
// without cgo.
//
// USE cgo WHEN:
//   - Wrapping a large, stable C library with no adequate pure-Go equivalent
//     (e.g., libsqlite3 for embedded SQL, OpenSSL for hardware crypto acceleration,
//     BLAS/LAPACK for linear algebra). The integration cost is paid once; the
//     ongoing call overhead is amortized over large C-side computations.
//
// DO NOT USE cgo WHEN:
//   - Calling a simple C utility function in a tight loop (the overhead dominates)
//   - A pure-Go library exists (prefer it: no build complexity, race detector works)
//   - The program must cross-compile easily (e.g., distributing binaries for multiple
//     platforms from a single CI machine without cross-compilers)

func main() {
    cgoDur := benchCgo()
    goDur := benchGo()

    cgoPerCall := float64(cgoDur.Nanoseconds()) / float64(N)
    goPerCall := float64(goDur.Nanoseconds()) / float64(N)

    fmt.Printf("cgo noop:  %v total, %.1f ns/call\n", cgoDur, cgoPerCall)
    fmt.Printf("Go  noop:  %v total, %.1f ns/call\n", goDur, goPerCall)
    fmt.Printf("Overhead ratio: %.1fx\n", cgoPerCall/goPerCall)
    // Expected output on a modern machine:
    // cgo noop:  ~1.5s total, ~150 ns/call
    // Go  noop:  ~30ms total, ~3 ns/call
    // Overhead ratio: ~50x
}

Scoring Log¶

Record your performance honestly. Include the date and whether you used hints.

Passing threshold: 11/17 (65%). Aim for 14/17 (82%) before taking the test.