fix data race on mutex.id in mutexTry non-recursive path

The non-recursive branch of mutexTry wrote mutex.id with a plain store while mutexHeld/mutexNotheld read it with atomic.LoadInt32.

Mixing atomic and non-atomic accesses to the same word is a data race under Go's memory model.

Use atomic.StoreInt32, consistent with every other write site (mutexEnter, mutexLeave, and the recursive branch of mutexTry).

I have a regression test for this, but I'm not convinced it is worth adding. It's a lot of code and compute for an obvious fix that is unlikely to regress.

Merge request reports

Loading