Hi Mattias! On Sat, Jun 20, 2015 at 4:32 AM, Mattias Engdegård <matti...@acm.org> wrote: > 19 jun 2015 kl. 23.12 skrev Alexandre Pereira Nunes > <alexandre.nu...@gmail.com>: > >> I came across this: https://sourceforge.net/p/mingw-w64/bugs/344/ >> >> Does anyone knows if that's still the case? > > Yes. There is a patch, but it has not been cleared for release yet. It may > take a few weeks more, given that people are on holiday. I shall try to > accelerate the process. > ...
Out of curiosity, do you know what approach the patch takes? I ask because std::thread supports timed waits on (timed) mutexes, and I believe that pthreads does as well. How does the patch implement timed waits? Quoting from the bug report cited above: Currently libwinpthread implements mutexes directly on top of Windows semaphores. Semaphores, being kernel objects, require kernel mode transition in order to lock or unlock, which is very slow compared to interlocked operations (as in, "up to several hundred times slower"). Suggestion: either base mutexes on Windows critical sections outright, or do the same thing "manually". If the solution is to base winpthread's mutexes on windows critical sections, you will have to address the issue of timed waits. I believe that windows critical sections offer no timed wait functionality. I see three ways to address this. Use critical sections as mutexes, but add additional helper objects (that support waits) to any timed wait call. I think this is doable, but seems unattractively complicated and will worsen performance. Write from scratch (i.e. don't use windows critical sections) your own mutexes that support timed waits. This ought to be doable, but would be some work and does seem like reinventing the wheel. (But, as I understand it, winpthread did write its own condition variables from scratch.) Recognize that std::thread (I don't know if this applies to pthreads or not) distinguishes between timed mutexes (that you can perform a timed wait on) and "regular" mutexes that do not support timed waits. In this case you could, for example, base "regular" mutexes on windows critical sections (no timed waits), and timed mutexes on windows semaphores (or windows mutexes). This has the disadvantage that you now have two different kinds of mutexes. (Why shouldn't you be able to perform a timed wait on any mutex?), but the "regular" mutexes should now be faster. I should note that both windows semaphores and windows mutexes (Both support timed waits.) are cross-process synchronization objects, whereas windows critical sections can only be used to synchronize threads within a single process (consistent with the single-process threading model supported by std::thread and pthreads). As cross-process objects they are heavier weight and less efficient, and this probably accounts for the mutex inefficiency described in the bug report. Best. K. Frank ------------------------------------------------------------------------------ _______________________________________________ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
