Go sync.Mutex: CAS Fast Path, Spinning, and Starvation Mode

Mutex state fields

type Mutex struct {
    state int32   // packed: locked bit + waiter count + flags
    sema  uint32  // semaphore for goroutine sleep/wake
}

const (
    mutexLocked          = 1 << iota  // bit 0: mutex is held
    mutexWoken                         // bit 1: a waiter is being woken
    mutexStarving                      // bit 2: starvation mode active
    mutexWaiterShift = iota           // bits 3+: waiter count
    starvationThresholdNs = 1e6       // 1ms before starvation mode
)

The state field packs multiple values into a single 32-bit integer: the lock bit, a "woken" flag (one goroutine is already being woken to avoid thundering herd), a starvation flag, and a 29-bit waiter count.

Fast path: uncontended lock

func (m *Mutex) Lock() {
    // Try to grab the lock with a single atomic CAS
    if atomic.CompareAndSwapInt32(&m.state, 0, mutexLocked) {
        return  // acquired — no syscall, no context switch
    }
    m.lockSlow()
}

atomic.CompareAndSwapInt32 is a CPU-level instruction (LOCK CMPXCHG on x86). If m.state == 0 (unlocked, no waiters), it atomically sets the locked bit and returns. The entire fast path is ~5 nanoseconds — no OS involvement.

Slow path: spinning then sleeping

When the CAS fails, lockSlow runs. It first spins:

// Spinning is allowed only when:
// - mutex is locked but NOT in starvation mode
// - runtime_canSpin: CPU count > 1, goroutine is running (not queued), <4 spins done
if old&(mutexLocked|mutexStarving) == mutexLocked && runtime_canSpin(iter) {
    runtime_doSpin()  // ~30 PAUSE instructions, yields CPU briefly
    iter++
    continue
}

After spinning, if the lock is still unavailable, the goroutine calls runtime_SemacquireMutex(&m.sema, ...) to sleep. The runtime parks the goroutine and records when it started waiting.

On Unlock():

func (m *Mutex) Unlock() {
    new := atomic.AddInt32(&m.state, -mutexLocked)  // clear locked bit
    if new != 0 {
        m.unlockSlow(new)  // wake a waiter if needed
    }
}

runtime_Semrelease wakes one sleeping goroutine, which retries the CAS.

RWMutex for read-heavy workloads

When reads vastly outnumber writes, sync.RWMutex allows concurrent reads:

var mu sync.RWMutex
var data map[string]string

// Multiple goroutines can hold RLock simultaneously
func read(key string) string {
    mu.RLock()
    defer mu.RUnlock()
    return data[key]
}

// Write requires exclusive access — blocks until all RLocks release
func write(key, value string) {
    mu.Lock()
    defer mu.Unlock()
    data[key] = value
}

RWMutex has a write-starvation problem of its own: if reads are continuous, a writer can wait indefinitely. The standard library's implementation gives writers priority once they start waiting — new RLock() calls block if a writer is queued.

var m sync.Map

m.Store("key", "value")

if v, ok := m.Load("key"); ok {
    fmt.Println(v)
}

// LoadOrStore: atomic check-and-set
actual, loaded := m.LoadOrStore("key", "new-value")
// loaded=true if key existed, actual = existing value