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://gist.github.com/sitsofe/abd99efec507b18234e7cc042d1baff1 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://sourceforge.net/p/mingw-w64/bugs/710/ 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 | http://sucs.org/~sits/ -- To unsubscribe from this list: send the line "unsubscribe fio" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
