Language-Level Concurrency and Multithreading Questions

Per-language and per-runtime concurrency: the threading and async APIs each language provides (goroutines and channels in Go, threads and executors in Java, async/await runtimes, C++ std::thread and atomics), each language's memory model, and the idioms for coordinating shared state safely in that language. Covers choosing and using a language's concurrency primitives correctly; OS-level scheduling, synchronization theory, and deadlock internals live in Operating Systems & Systems Programming.

HardTechnical

23 practiced

A Go service leaks goroutines because some goroutines block on network reads and never exit on shutdown. Propose and describe code changes to ensure deterministic shutdown and that goroutines exit: include use of context.Context, listener.Close(), deadlines, WaitGroup patterns, and how to verify no leaks remain in production.

Sample Answer

Approach (brief): use context.Context to broadcast shutdown, close listeners to unblock Accept, set per-connection deadlines or use io.ReadWithContext patterns to unblock blocked Reads, coordinate goroutine lifecycle with sync.WaitGroup, and verify with pprof/goroutine snapshots, tests, and production metrics. Code (concise, key parts): gopackage main import ( "context" "net" "sync" "time" ) type Server struct { ln net.Listener wg sync.WaitGroup done context.CancelFunc ctx context.Context } func NewServer(ln net.Listener) *Server { ctx, cancel := context.WithCancel(context.Background()) return &Server{ln: ln, ctx: ctx, done: cancel} } func (s *Server) Serve() error { for { conn, err := s.ln.Accept() if err != nil { select { case <-s.ctx.Done(): return nil // expected during shutdown default: return err } } s.wg.Add(1) go s.handleConn(conn) } } func (s *Server) handleConn(conn net.Conn) { defer s.wg.Done() defer conn.Close() // Short read deadline so blocked reads wake periodically to check ctx const idle = 5 * time.Second buf := make([]byte, 4096) for { // set a deadline so Read unblocks regularly _ = conn.SetReadDeadline(time.Now().Add(idle)) n, err := conn.Read(buf) if n > 0 { // process data... } if err != nil { // check if deadline or temporary, or context canceled if ne, ok := err.(net.Error); ok && ne.Timeout() { select { case <-s.ctx.Done(): return default: continue } } return } } } func (s *Server) Shutdown(timeout time.Duration) error { // signal goroutines to stop s.done() // close listener to unblock Accept s.ln.Close() // wait with timeout for goroutines to exit c := make(chan struct{}) go func() { s.wg.Wait() close(c) }() select { case <-c: return nil case <-time.After(timeout): return context.DeadlineExceeded } } Key reasoning: Context cancelation broadcasts intent; goroutines check ctx.Done(). listener.Close() unblocks Accept immediately. Read deadlines ensure blocked Reads wake periodically to observe ctx.Done() without relying on platform-specific behavior. WaitGroup gives deterministic wait for goroutine termination; Shutdown uses timeout to avoid indefinite blocking. Edge cases: Long deadlines slow shutdown; choose deadlines vs. more complex interruptible I/O (e.g., Read with context or using netpoll). Ensure all spawned goroutines are accounted for in wg.Add/Done. For TLS or HTTP servers, use http.Server.Shutdown which follows similar patterns. Verification / preventing regressions: Unit/integration tests: create test listener, simulate clients stuck on read, assert Shutdown returns within timeout and goroutine count stable. Use runtime/pprof.Lookup("goroutine").WriteTo(...) in tests to assert no leaked goroutines. Run with -race in CI. Production: export goroutine_count metric, alert on sustained growth; collect periodic pprof goroutine profiles (e.g., with go tool pprof or via /debug/pprof) and analyze stack traces for blocked Read or waiting on network. Use chaos tests (kill listener, simulate slow clients) in staging to verify deterministic shutdown. This pattern yields deterministic shutdown, minimal code changes, and measurable verifications to prevent regressions.

HardTechnical

23 practiced

In Go, write a function that runs multiple independent checks in parallel, returns all failures in a single error value, and preserves enough context for an operator to diagnose the problem quickly. The function should respect context cancellation by stopping new work and allowing in-flight checks to exit promptly.

Sample Answer

I’d use errgroup for parallel execution plus a custom multi-error type that preserves context for each failed check. Behavior: Start all checks concurrently. Stop launching new work if the context is canceled. Let in-flight checks exit quickly by passing the same context. Collect each failure with its check name and error message. gopackage checks import ( "context" "fmt" "strings" "sync" ) type ItemError struct { Name string; Err error } type MultiError struct { Items []ItemError } func (m MultiError) Error() string { parts := make([]string, 0, len(m.Items)) for _, it := range m.Items { parts = append(parts, fmt.Sprintf("%s: %v", it.Name, it.Err)) } return strings.Join(parts, "; ") } func Run(ctx context.Context, checks map[string]func(context.Context) error) error { var mu sync.Mutex var items []ItemError var wg sync.WaitGroup for name, fn := range checks { if ctx.Err() != nil { break } wg.Add(1) go func(name string, fn func(context.Context) error) { defer wg.Done() if err := fn(ctx); err != nil { mu.Lock(); items = append(items, ItemError{name, err}); mu.Unlock() } }(name, fn) } wg.Wait() if len(items) == 0 { return nil } return MultiError{Items: items} } Diagnostics: include the check name, target host, and operation in the error text so on-call can triage quickly. For verification, I’d use short deadlines, inject failures, and run go test -race to ensure aggregation is safe.

MediumTechnical

26 practiced

Write a concurrent log processor in Go that reads from multiple log files and extracts metrics using a worker pool. Requirements: preserve per-file line order when sending extracted records to downstream processing, support backpressure if downstream is slow, and avoid processing the same line twice on restarts if check-pointed offsets are used.

Sample Answer

Approach: Spawn one reader goroutine per file that tails the file starting at a checkpointed offset, reads lines, assigns a monotonically increasing sequence number, and sends line+meta to a shared worker input channel. Start a pool of worker goroutines that parse/extract metrics and return results tagged with file ID and sequence number to a per-file result channel. For each file run a sequencer goroutine that buffers results and emits them in-order to downstream. Emit uses a blocking send so downstream slowness applies backpressure all the way to readers (via limited channel buffers). Checkpoint offsets only after the sequencer successfully delivers a record downstream (acknowledged / durable), preventing re-processing on restart. Example implementation (simplified): gopackage main import ( "bufio" "fmt" "io" "os" "sync" ) type LineTask struct { FileID string Seq int64 Offset int64 Line string } type Result struct { FileID string Seq int64 Offset int64 Metric map[string]int Err error } func reader(filePath, fileID string, startOffset int64, tasks chan<- LineTask, done <-chan struct{}, wg *sync.WaitGroup) { defer wg.Done() f, err := os.Open(filePath) if err != nil { return } defer f.Close() // seek to startOffset (checkpoint) f.Seek(startOffset, io.SeekStart) r := bufio.NewReader(f) var seq int64 = 0 var offset int64 = startOffset for { select { case <-done: return default: } line, err := r.ReadString('\n') if err != nil { if err == io.EOF { // simple tailing: sleep briefly // in production use fsnotify or polling with backoff continue } return } // note: offset calculation here is illustrative tasks <- LineTask{FileID: fileID, Seq: seq, Offset: offset, Line: line} offset += int64(len(line)) seq++ } } func worker(tasks <-chan LineTask, results chan<- Result, wg *sync.WaitGroup) { defer wg.Done() for t := range tasks { // simulate parsing/extracting metrics metric := map[string]int{"lines": 1} results <- Result{FileID: t.FileID, Seq: t.Seq, Offset: t.Offset, Metric: metric} } } func sequencer(fileID string, results <-chan Result, downstream chan<- Result, checkpointFn func(fileID string, offset int64) error, done <-chan struct{}, wg *sync.WaitGroup) { defer wg.Done() next := int64(0) buf := make(map[int64]Result) for { select { case <-done: return case r, ok := <-results: if !ok { // drain buffered in-order for { if res, exists := buf[next]; exists { downstream <- res checkpointFn(fileID, res.Offset) delete(buf, next) next++ } else { return } } } if r.Seq == next { downstream <- r checkpointFn(fileID, r.Offset) next++ // flush any buffered in-order for { if res, exists := buf[next]; exists { downstream <- res checkpointFn(fileID, res.Offset) delete(buf, next) next++ } else { break } } } else { buf[r.Seq] = r } } } } func main() { // channels with small buffers to enable backpressure tasks := make(chan LineTask, 100) results := make(chan Result, 100) downstream := make(chan Result, 10) // downstream consumer limited => backpressure done := make(chan struct{}) var wg sync.WaitGroup // start workers for i := 0; i < 5; i++ { wg.Add(1) go worker(tasks, results, &wg) } // per-file readers & sequencers (example with 2 files) files := []struct{ path, id string }{{"app.log","app"}, {"db.log","db"}} for _, f := range files { wg.Add(1) go reader(f.path, f.id, 0, tasks, done, &wg) // load startOffset from checkpoint in real code // create per-file results channel and sequencer fileResults := make(chan Result, 100) // demultiplex results into per-file channels go func(fr chan<- Result) { for r := range results { if r.FileID == f.id { fr <- r } } close(fr) }(fileResults) wg.Add(1) go sequencer(f.id, fileResults, downstream, func(fileID string, offset int64) error { // persist checkpoint atomically (e.g., write to durable store) fmt.Printf("checkpoint %s -> %d\n", fileID, offset) return nil }, done, &wg) } // downstream consumer (simulated) go func() { for r := range downstream { // process or forward metrics (could be slow) fmt.Printf("downstream got %v seq=%d\n", r.FileID, r.Seq) } }() // wait or handle signals... } Key points / reasoning: Per-file seq + sequencer guarantees per-file ordering while enabling concurrent parsing. Downstream channel with limited buffer plus blocking sends enforces backpressure that propagates to workers and readers (bounded channels). Checkpointing after sequencer delivery (durable persist of offset) prevents re-processing on restart. In practice use atomic writes (e.g., write-new-file+rename or transactional store). Use tailing library, fsnotify, or Kafka-like log ingestion for production. Complexity: Work is O(N) over lines. Memory: per-file buffer size equals number of out-of-order results; tune worker count and channel buffers to bound memory. Edge cases: Long-running out-of-order buffer if a worker is stuck — add timeouts / retries. Exactly-once requires idempotent downstream or transactional checkpoint+publish. Crash between downstream ack and checkpoint: design durable commit protocol (e.g., write-ahead).

MediumTechnical

23 practiced

In Go, implement a worker pool that processes a list of jobs concurrently and returns the results in the same order as the input. The pool should limit concurrency to a fixed number of workers and avoid leaking goroutines if one job fails. Describe the data structures you would use and why.

Sample Answer

I’d model each job with its original index so I can preserve input order, and I’d use a bounded worker pool plus a results channel. Data structures jobs []Job with index field results []Result sized to the number of jobs jobCh for distributing work errCh or context.Context for early cancellation Why The index lets me place each result back into the correct slot, while the bounded worker count prevents unbounded goroutine growth. Go approach go type Job struct { Index int Value string } type Result struct { Index int Value string Err error } Workers read from jobCh, process one job, and send a Result with the same index. A collector writes results into a preallocated slice. If any job fails, I cancel the context so remaining workers stop quickly and don’t leak. Operational details Close channels from the sender side only Use WaitGroup to ensure workers exit Return partial results only if the API explicitly allows it Complexity Time: O(n), assuming per-job work is O(1) Space: O(n) for ordered results, O(workers) for concurrency control For SRE tasks, this pattern is solid for batch remediation jobs where correctness and cleanup matter as much as throughput.

HardTechnical

25 practiced

In Go, implement a fan-out/fan-in pipeline that sends the same request to multiple backends, returns the first successful response, and cancels the remaining work immediately. The solution must not leak goroutines, must collect all errors if every backend fails, and must respect a parent context.

Sample Answer

I’d implement this with a parent context, one goroutine per backend, and a result channel buffered to the number of backends so nothing blocks on shutdown. Flow: Derive a cancelable child context from the parent. Fan out requests to all backends. Return the first successful response and call cancel() immediately. If all fail, collect errors and return a combined error. Drain goroutines via WaitGroup so there are no leaks. gopackage main import ( "context" "fmt" "sync" ) type Result struct { Value string; Err error } func QueryAny(ctx context.Context, backends []func(context.Context) (string, error)) (string, error) { ctx, cancel := context.WithCancel(ctx) defer cancel() results := make(chan Result, len(backends)) var wg sync.WaitGroup for _, b := range backends { wg.Add(1) go func(fn func(context.Context) (string, error)) { defer wg.Done() v, err := fn(ctx) select { case results <- Result{v, err}: case <-ctx.Done(): } }(b) } go func() { wg.Wait(); close(results) }() var errs []error for r := range results { if r.Err == nil { cancel() return r.Value, nil } errs = append(errs, r.Err) } return "", fmt.Errorf("all backends failed: %v", errs) } This pattern is reliable for SRE tooling because it minimizes tail latency, respects cancellation, and avoids goroutine leaks under partial failure.

That is every published Language-Level Concurrency and Multithreading question for Site Reliability Engineer (SRE) so far. Browse the other topics in this category, or practice this one interactively.

Browse Programming Languages & Core Development topics Start a practice session