Go’s race detector has a mutex blind spot

Post by klabb3 » Thu, Jul 31, 2025, 5:14 PM UTC

gf000 wrote: post #28

Xeoncross wrote: post #11

Earlier quoted context omitted.

> and 'f' panics, the program's deadlocked forever I don't see `mu.Lock(); f(); mu.Unlock()` anywhere really. `mu.Lock(); defer mu.Unlock(); f();` is how everyone does it to prevent that possibility.

Trick question: what is the scope of `defer` in go?

Post by bheadmaster » Thu, Jul 31, 2025, 5:33 PM UTC

tialaramex wrote: post #30

Xeoncross wrote: post #15

I'm so glad to be out of the dark ages of parallelism. Complaining about Go's race detector or exactly which types of logical races Rust can't prevent is such a breath of fresh air compared to all those other single-core languages we're paid to write with that had threading, async, or concurrency bolted-on as an afterthought. I can only hope Go and Rust continue to improve until the next language generation comes alo…

You know how a modern language like Rust doesn't have the unstructured control flow with features like "goto"† but only a set of structured control flow features, such as pattern matching, conditionals, loops and functions? Structured Concurrency is the same idea, but for concurrency. Instead of that code to create an appropriate number of threads, parcel out work, and so on, you just express high level goals like "D…

Post by ezst » Thu, Jul 31, 2025, 6:01 PM UTC

tialaramex wrote: post #30

Xeoncross wrote: post #15

I'm so glad to be out of the dark ages of parallelism. Complaining about Go's race detector or exactly which types of logical races Rust can't prevent is such a breath of fresh air compared to all those other single-core languages we're paid to write with that had threading, async, or concurrency bolted-on as an afterthought. I can only hope Go and Rust continue to improve until the next language generation comes alo…

You know how a modern language like Rust doesn't have the unstructured control flow with features like "goto"† but only a set of structured control flow features, such as pattern matching, conditionals, loops and functions? Structured Concurrency is the same idea, but for concurrency. Instead of that code to create an appropriate number of threads, parcel out work, and so on, you just express high level goals like "D…

Post by dfawcus » Thu, Jul 31, 2025, 10:26 PM UTC

ViewTrick1002 wrote: post #23

jerf wrote: post #20

Earlier quoted context omitted.

OK, but you're not in "Go"-specific problems any more, that's just concurrency issues. There isn't any approach to concurrency that will rigorously prevent programmers from writing code that doesn't progress sufficiently, not even going to the extremes of Erlang or Haskell. Even when there are no locks qua locks to be seen in the system at all I've written code that starved the system for resources by doing things li…

I would say it is a Go specific problem with how mutexes and defer are used together. In rust you would just throw a block around the mutex access changing the scoping and ensuring it is dropped before the slow function is called. Call it a minimally intrusive manual unlock.

  type Foo struct {sync.Mutex; s string}
  
  func doLocked[T sync.Locker](data T, fn func(data T)) {
      data.Lock(); defer data.Unlock(); fn(data)
  }
  
  func main() {
      foo := &Foo{s: "Hello"}
      doLocked(foo, func(foo *Foo) {
        /* ... */
      })
      /* do the slow stuff */
  }

Post by pjmlp » Fri, Aug 01, 2025, 9:30 AM UTC

chrchang523 wrote: post #45

klabb3 wrote: post #42

Earlier quoted context omitted.

Function body, so no don’t put it in your loop. Just break it out to a helper fn if needed. This isn’t a big problem in practice.

Yes, though I think tooling could be better; if I had more spare time I'd write a linter which flagged defers in loops that didn't come with an accompanying comment.