[Golang] Avoid Using `defer mu.Unlock()` Inside Loops

In Go, using a mutex with defer might seem like an elegant and safe way to manage your code by ensuring resources are properly released. However, a common mistake lurks when this pattern is used inside loops.

When working with mutexes, never do this:

func broadcast(ctx context.Context, msgCh <-chan Message) {
  for {
    select {
      case msg := <-msgCh:
        s.mu.Lock()
        defer s.mu.Unlock() // ❌ Avoid this

        // Use the shared resource here          

      case <-ctx.Done():
        return
    }
  }
}

This seemingly harmless pattern can cause unexpected behavior and should be avoided. Let’s look into why this happens and how to handle it correctly.

The Rule

Do not use defer mu.Unlock() inside loops that don’t exit per iteration.

If this rule isn’t followed, the deferred mu.Unlock() might not run where you expect it to, leading to potential deadlocks.

What Happens Under the Hood

In Go, defer functions execute when the surrounding function exits, not at the end of each loop iteration. This can lead to multiple locks without any corresponding unlocks taking place immediately:

for {
  s.mu.Lock()
  defer s.mu.Unlock()
}

Here’s how it actually behaves:

s.mu.Lock()
s.mu.Lock()
s.mu.Lock()
...

The loop keeps acquiring locks, while mu.Unlock() is queued to execute only when the enclosing function terminates. This can result in a deadlock situation because unlocks occur too late, if at all.

The Correct Way

To safely handle mutexes within loops, manage unlocking explicitly at the end of each critical section like this:

func broadcast(ctx context.Context, msgCh <-chan Message) {
  for {
    select {
      case msg := <-msgCh:
        s.mu.Lock()
       
        // Critical section: safely access shared resources

        s.mu.Unlock()
      
      case <-ctx.Done():
        return
    }
  }
}

By unlocking right after processing, you ensure:

• Every lock has a corresponding unlock within the same iteration, preventing deadlock scenarios.
• There are no deferred calls accumulating, providing clarity and safety.

If You Prefer defer

If the readability and error-handling benefits of defer are appealing, consider wrapping the lock logic within an anonymous function. This allows defer to behave correctly:

func broadcast(ctx context.Context, msgCh <-chan Message) {
  for {
    select {
      case msg := <-msgCh:
        func() {   // ✅ Wrap in anonymous function
          s.mu.Lock()
          defer s.mu.Unlock()

          // Use the shared resource here

        }()

      case <-ctx.Done():
        return
    }
  }
}

Using an anonymous function ensures that defer runs each time the function concludes, keeping locks and unlocks aligned.

One More Thing

When performing slow operations in critical section, like network I/O, holding a lock can severely degrade performance and increase deadlock risk. For example:

...
  func() {
    s.mu.Lock()
    defer s.mu.Unlock()

    // Critical section: safely access shared resources
    for _, client := range clients {
      client.Conn.Write(...)  // ❌ Holding lock during slow operation
    }
  }()
...

Instead, release the lock before such operations:

...
  func() {
    s.mu.Lock()
    clients := copyClients(s.clients) // ✅ Copy necessary data while holding the lock
    s.mu.Unlock()

    // Critical section: safely access shared resources
    for _, client := range clients {
      client.Conn.Write(...)
    }
  }()
...

With this pattern, you copy necessary data while holding the lock and release it promptly, ensuring that lengthy operations don’t hold up resources.

Summary

To sum up, efficiently managing locks in Go with sync.Mutex involves understanding the behavior of defer:

• Avoid placing defer mu.Unlock() inside loops—it doesn’t release locks per iteration.
• Use explicit mu.Unlock() calls within the loop body.
• Preferably, encapsulate loop logic within an anonymous function if using defer.
• Keep critical sections small and free from slow operations to avoid bottlenecks.

These practices will help you sidestep common pitfalls and utilize Go’s concurrency model to create robust and efficient applications.