From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: MIME-Version: 1.0 In-Reply-To: <406902be-f4ce-c4f4-4e16-ee9caf8c0bcf@kernel.dk> References: <9cf7d62a-5c4a-737a-d119-13763fb42c72@bluestop.org> <36259BEC-1CF0-45A5-85AE-F557989EDF30@nutanix.com> <2B8D69D8-05F3-4500-8A4E-F5DE21356676@nutanix.com> <971ECD81-B100-4EEE-98CE-0E578A59BB02@nutanix.com> <7B5FFC71-BE67-435F-8DE6-8376E52754EB@nutanix.com> <406902be-f4ce-c4f4-4e16-ee9caf8c0bcf@kernel.dk> From: Sitsofe Wheeler Date: Fri, 16 Mar 2018 08:13:50 +0000 Message-ID: Subject: Re: Windows: FIO randomly hangs using attached script Content-Type: text/plain; charset="UTF-8" To: Jens Axboe Cc: Rob Scheepens , David Knierim , Rebecca Cran , fio List-ID: On 9 March 2018 at 14:55, Jens Axboe 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/