Re: [PATCH v2] Fix races in Windows pthread emulation

Yes, the else branch covers GNU-style Windows builds. The current
mingw-w64 winnt.h doesn't provide ReadAcquire, so I used
__atomic_load_n there.

InterlockedCompareExchange(&mp->initstate, 0, 0) would provide a
common implementation with a full memory barrier. It would also put a
compare-exchange operation back on the initialized fast path. Avoiding
that was the reason for the split; I haven't benchmarked the
difference.

I haven't identified a common load-only Windows primitive in the
headers checked. I suggest keeping the load-only paths unless you'd
prefer the simpler common API path.

Best,

Harrison

On Tue, 13 Oct 2026 11:03:21 +0300, Heikki Linnakangas <hlinnaka(at)iki(dot)fi> wrote:
> On 13/10/2026 02:37, harrisontbooth(at)gmail(dot)com wrote:
> > Heikki, do the acquire loads and separate pthread_once work address
> > your concerns?
>
> Yeah.
>
> > + /* Acquire the initialization state without a read-modify-write. */
> > +#ifdef _MSC_VER
> > + if (ReadAcquire(&mp->initstate) != 1)
> > +#else
> > + if (__atomic_load_n(&mp->initstate, __ATOMIC_ACQUIRE) != 1)
> > +#endif
>
> Hmm, so ReadAcquire is only available on Visual Studio, and the
> else-branch is for mingw builds? Is there no atomic read intrinsic
> similar InterlockedCompareExchange() that would work on both?
>
> - Heikki