Closing the loop on this: after running a couple of million times the script that used to reproduce this, I have not seen a single error with the patch.
Thanks All for the great work on this!
\Rob
On 16/03/2018, 09:14, "Sitsofe Wheeler" <sitsofe@xxxxxxxxx> wrote:
On 9 March 2018 at 14:55, Jens Axboe <axboe@xxxxxxxxx> wrote:
>
> In some implementations it's actually mandated to have the wakeup
> within the lock, which seems to be the case here. It's a shame,
> since it's clearly suboptimal (from a scalability point of view)
> to have to hold the lock while issuing a wakeup for a process
> that's going to grab the same lock.
>
> I'll commit the patch. Thanks a lot for all your hard work on this
> one, let's hope that was it...
FWIW this has been accepted as a bug in the mingw-w64 project's
winpthreads library. The standalone program on
https://urldefense.proofpoint.com/v2/url?u=https-3A__gist.github.com_sitsofe_abd99efec507b18234e7cc042d1baff1&d=DwIBaQ&c=s883GpUCOChKOHiocYtGcg&r=OMged-t_5I_fmfpUaT3vaA06lgLL_alYnDQJxHmXz64&m=C-SjzVSuoSBlexryZgGqFEfxhSdPbozUDu3U82Yjmqs&s=Xri6zcEiOde_B9rOwAyOAqm92oyNy-W5DHk01BPTQ_I&e=
reliably triggers the deadlock for me when using a mingw build on both
real Windows and under Wine but not when built for Linux with glibc.
See https://urldefense.proofpoint.com/v2/url?u=https-3A__sourceforge.net_p_mingw-2Dw64_bugs_710_&d=DwIBaQ&c=s883GpUCOChKOHiocYtGcg&r=OMged-t_5I_fmfpUaT3vaA06lgLL_alYnDQJxHmXz64&m=C-SjzVSuoSBlexryZgGqFEfxhSdPbozUDu3U82Yjmqs&s=Ms3hnbtg0t-Ycfm-kLxkR0pvsG1BpG6Ch-oyrsk6h4Y&e= for the "Deadlock in
winpthreads' pthread_cond_signal()" bug.
Rob, David, Rebecca: do you know if the current git fio cures the
deadlock you were seeing?
--
Sitsofe | https://urldefense.proofpoint.com/v2/url?u=http-3A__sucs.org_-7Esits_&d=DwIBaQ&c=s883GpUCOChKOHiocYtGcg&r=OMged-t_5I_fmfpUaT3vaA06lgLL_alYnDQJxHmXz64&m=C-SjzVSuoSBlexryZgGqFEfxhSdPbozUDu3U82Yjmqs&s=Chc6sQtGY11L4YRP_re07gL3JfHJosjt_F6tVk-WdsQ&e=
��.n��������+%������w��{.n�������^n�r������&��z�ޗ�zf���h���~����������_��+v���)ߣ�
