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

Hi,

Thank you for working on this!

On Fri, 24 Jul 2026 at 10:07, Harrison Booth <harrisontbooth(at)gmail(dot)com> wrote:
>
> On native Windows ARM64, the ECPG thread/alloc test could hang until
> Meson's 1000-second timeout. The cause was a race in the Windows pthread
> mutex emulation.

I ran into this exact issue today [1] and found your thread.

> The mutex initialization path used InterlockedExchange to set initstate to
> 2. A waiting thread could therefore change the fully initialized state from
> 1 back to 2. pthread_mutex_unlock would then see a state other than 1,
> return EINVAL, and leave the critical section locked.

I tried to understand the problem and the related Windows thread
functions, please correct my understanding:

1- In pthread_mutex_lock(), calling
InterlockedExchange(&mp->initstate, 2) writes unconditionally,
clobbering an initialized state 1 back to 2.
2- The thread enters the critical section while mp->initstate = 2.
3- Later, when pthread_mutex_unlock() is called, if (mp->initstate !=
1) evaluates to true, causing the function to return EINVAL without
releasing the underlying critical section, leading to a deadlock.

And your patch fixes this problem with
InterlockedCompareExchange(&mp->initstate, 2, 0), because now you
check the initial value so that you can't overwrite 1 with 2.

[1] https://github.com/nbyavuz/postgres/actions/runs/32351446950/job/96371608653

--
Regards,
Nazir Bilal Yavuz
Microsoft