Reid Kleckner
2014-Jun-20 18:09 UTC
[LLVMdev] [PATCH] Replace the Execution Engine's mutex with std::recursive_mutex
OK, sounds like we're screwed. There's two options: 1. Revert and give up on C++11 threading libraries for now. 2. Do what Eric suggests. Move all the mutex usage under #ifdef LLVM_ENABLE_THREADS, and disable LLVM_ENABLE_THREADS by default on MinGW. MinGW plus LLVM_ENABLE_THREADS would become unsupported. Do people have objections to 2? I don't really like it either. On Fri, Jun 20, 2014 at 10:33 AM, Yaron Keren <yaron.keren at gmail.com> wrote:> The whole "mutex" and "shared_mutex" files are #ifdef > _GLIBCXX_HAS_GTHREADS so if no _GLIBCXX_HAS_GTHREADS there are no mutexes > and no call_once. thread lives in "thread" which is also #ifdef > _GLIBCXX_HAS_GTHREADS. > "condition_variable" and "future" are the same. > > I have tested gcc 4.8.2 predefines and _GLIBCXX_HAS_GTHREADS isn't there > nor it is defined anywhere with the win32 version. I have also compiled a > small test and indeed it failed with > > a.cpp:4:3: error: 'mutex' is not a member of 'std'. > > Just for fun, I tried to compile it with -D_GLIBCXX_HAS_GTHREADS but then > it failed on bunch of other errors starting with > > error: '__gthread_time_t' was not declared in this scope > > so gthreads isn't there. > > As to popularity, compare the download graphs for 32 bit: > > > http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win32/Personal%20Builds/mingw-builds/4.9.0/ > > and 64 bit: > > > http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win64/Personal%20Builds/mingw-builds/4.9.0/ > > in 32 bit the posix version rules, whereas in 64 bit it is a close winner. > If you go back to 4.8.2 the pattern is similar. > > The win32 version does not support anything thread-related so it's not > C++11 compliant? > > Yaron > > > > 2014-06-20 19:55 GMT+03:00 Reid Kleckner <rnk at google.com>: > >> It sounds like this version of libstdc++ doesn't support >> std::recursive_mutex from C++11. This is really unfortunate, because we >> were hoping that moving to C++11 would allow us to use standard, portable >> threading primitives. >> >> Does this version of MinGW have any C++11 threading support? Is it just >> recursive_mutex that is missing, or do we have to avoid std::mutex, >> std::call_once, etc? lld has been using all of these things for some time >> now, and in theory we have the same baseline toolchain requirements. >> >> If it's just std::recursive_mutex, how long do you think it would take to >> implement that for mingw's libstdc++? >> >> Do you have a sense of which version of mingw is more popular, the >> pthreads variant or the win32 threads variant? If the overwhelming >> majority use the win32 threads variant, I don't think we can break it. >> >> >> On Fri, Jun 20, 2014 at 9:49 AM, Zachary Turner <zturner at google.com> >> wrote: >> >>> I kind of feel like we should drop support for this configuration. Here >>> are the reasons why: >>> >>> 1) clang, lld, and other LLVM-based tools already make use of >>> std::recursive_mutex and std::mutex, so if those types don't exist in this >>> one configuration, we have already (even if inadvertently) made a statement >>> that we don't support that configuration. >>> >>> 2) We chose C++11 as the baseline because all compilers should support >>> it. This functionality in particular is pretty egregious to not support, >>> considering how simple it is. >>> >>> 3) Not supporting this configuration does not mean we don't support GCC >>> / MinGW, it only means we don't support GCC / MinGW / threads-win32. >>> There is still the threads-posix flavor of this platform which works fine >>> on Windows. >>> >>> #3 is a little unfortunate and backwards, since on Windows we should be >>> encouraging native Windows implementations of things and discouraging posix >>> emulation, but in this case the functionality just isn't implemented. >>> >>> >>> On Fri, Jun 20, 2014 at 9:26 AM, Zachary Turner <zturner at google.com> >>> wrote: >>> >>>> +llvmdev. >>>> >>>> I find this pretty surprising. Actually, we already use std::mutex and >>>> std::recursive_mutex in clang, lld, and other llvm projects, it's just a >>>> coincidence that it hadn't been introduced into LLVM until my commits. >>>> >>>> I'm not sure what the right thing to do here is. If I understand >>>> correctly, it seems like in order to encounter this, a) you must be using >>>> GCC, b) you must be using the MinGW flavor of GCC, and c) you must be using >>>> the threads-win32 flavor of this toolchain. Only if all 3 of those are >>>> true, then std::mutex and std::recursive_mutex don't exist. >>>> >>>> Anybody else have thoughts on whether this necessitates reverting the >>>> mutex changes, or whether this toolchain configuration should be supported? >>>> >>>> >>>> On Fri, Jun 20, 2014 at 12:07 AM, Vadim Chugunov <vadimcn at gmail.com> >>>> wrote: >>>> >>>>> FYI - this commit broke LLVM build using [[ >>>>> http://stackoverflow.com/questions/13212342/whats-the-difference-between-thread-posixs-and-thread-win32-in-gcc-port-of-windo >>>>> | win32 threads ]] flavor of the mingw toolchain. I am getting [[ >>>>> http://stackoverflow.com/questions/14191566/c-mutex-in-namespace-std-does-not-name-a-type >>>>> | error: 'recursive_mutex' in namespace 'std' does not name a type ]]. >>>>> Not sure if this would be considered a problem for LLVM... >>>>> >>>>> http://reviews.llvm.org/D4196 >>>>> >>>>> >>>>> >>>> >>> >> >> _______________________________________________ >> LLVM Developers mailing list >> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >> >> >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140620/b4c10504/attachment.html>
Zachary Turner
2014-Jun-20 18:14 UTC
[LLVMdev] [PATCH] Replace the Execution Engine's mutex with std::recursive_mutex
#2 is better if we can detect threads-win32 vs threads-posix on MinGW, and only disable this for threads-posix. We can check for _GLIBCXX_HAS_GTHREADS, but that seems somewhat hackish, so I wonder if there's a better way. To handle the switching, I guess we'll have to go back to the original option of having llvm::mutex, llvm::recursive_mutex, etc, and then conditionally typedefing them. Kinda sucks, but still better than getting rid of it entirely. On Fri, Jun 20, 2014 at 11:09 AM, Reid Kleckner <rnk at google.com> wrote:> OK, sounds like we're screwed. > > There's two options: > 1. Revert and give up on C++11 threading libraries for now. > 2. Do what Eric suggests. Move all the mutex usage under #ifdef > LLVM_ENABLE_THREADS, and disable LLVM_ENABLE_THREADS by default on MinGW. > MinGW plus LLVM_ENABLE_THREADS would become unsupported. > > Do people have objections to 2? I don't really like it either. > > > On Fri, Jun 20, 2014 at 10:33 AM, Yaron Keren <yaron.keren at gmail.com> > wrote: > >> The whole "mutex" and "shared_mutex" files are #ifdef >> _GLIBCXX_HAS_GTHREADS so if no _GLIBCXX_HAS_GTHREADS there are no mutexes >> and no call_once. thread lives in "thread" which is also #ifdef >> _GLIBCXX_HAS_GTHREADS. >> "condition_variable" and "future" are the same. >> >> I have tested gcc 4.8.2 predefines and _GLIBCXX_HAS_GTHREADS isn't there >> nor it is defined anywhere with the win32 version. I have also compiled a >> small test and indeed it failed with >> >> a.cpp:4:3: error: 'mutex' is not a member of 'std'. >> >> Just for fun, I tried to compile it with -D_GLIBCXX_HAS_GTHREADS but >> then it failed on bunch of other errors starting with >> >> error: '__gthread_time_t' was not declared in this scope >> >> so gthreads isn't there. >> >> As to popularity, compare the download graphs for 32 bit: >> >> >> http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win32/Personal%20Builds/mingw-builds/4.9.0/ >> >> and 64 bit: >> >> >> http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win64/Personal%20Builds/mingw-builds/4.9.0/ >> >> in 32 bit the posix version rules, whereas in 64 bit it is a close >> winner. If you go back to 4.8.2 the pattern is similar. >> >> The win32 version does not support anything thread-related so it's not >> C++11 compliant? >> >> Yaron >> >> >> >> 2014-06-20 19:55 GMT+03:00 Reid Kleckner <rnk at google.com>: >> >>> It sounds like this version of libstdc++ doesn't support >>> std::recursive_mutex from C++11. This is really unfortunate, because we >>> were hoping that moving to C++11 would allow us to use standard, portable >>> threading primitives. >>> >>> Does this version of MinGW have any C++11 threading support? Is it just >>> recursive_mutex that is missing, or do we have to avoid std::mutex, >>> std::call_once, etc? lld has been using all of these things for some time >>> now, and in theory we have the same baseline toolchain requirements. >>> >>> If it's just std::recursive_mutex, how long do you think it would take >>> to implement that for mingw's libstdc++? >>> >>> Do you have a sense of which version of mingw is more popular, the >>> pthreads variant or the win32 threads variant? If the overwhelming >>> majority use the win32 threads variant, I don't think we can break it. >>> >>> >>> On Fri, Jun 20, 2014 at 9:49 AM, Zachary Turner <zturner at google.com> >>> wrote: >>> >>>> I kind of feel like we should drop support for this configuration. >>>> Here are the reasons why: >>>> >>>> 1) clang, lld, and other LLVM-based tools already make use of >>>> std::recursive_mutex and std::mutex, so if those types don't exist in this >>>> one configuration, we have already (even if inadvertently) made a statement >>>> that we don't support that configuration. >>>> >>>> 2) We chose C++11 as the baseline because all compilers should support >>>> it. This functionality in particular is pretty egregious to not support, >>>> considering how simple it is. >>>> >>>> 3) Not supporting this configuration does not mean we don't support GCC >>>> / MinGW, it only means we don't support GCC / MinGW / threads-win32. >>>> There is still the threads-posix flavor of this platform which works fine >>>> on Windows. >>>> >>>> #3 is a little unfortunate and backwards, since on Windows we should be >>>> encouraging native Windows implementations of things and discouraging posix >>>> emulation, but in this case the functionality just isn't implemented. >>>> >>>> >>>> On Fri, Jun 20, 2014 at 9:26 AM, Zachary Turner <zturner at google.com> >>>> wrote: >>>> >>>>> +llvmdev. >>>>> >>>>> I find this pretty surprising. Actually, we already use std::mutex >>>>> and std::recursive_mutex in clang, lld, and other llvm projects, it's just >>>>> a coincidence that it hadn't been introduced into LLVM until my commits. >>>>> >>>>> I'm not sure what the right thing to do here is. If I understand >>>>> correctly, it seems like in order to encounter this, a) you must be using >>>>> GCC, b) you must be using the MinGW flavor of GCC, and c) you must be using >>>>> the threads-win32 flavor of this toolchain. Only if all 3 of those are >>>>> true, then std::mutex and std::recursive_mutex don't exist. >>>>> >>>>> Anybody else have thoughts on whether this necessitates reverting the >>>>> mutex changes, or whether this toolchain configuration should be supported? >>>>> >>>>> >>>>> On Fri, Jun 20, 2014 at 12:07 AM, Vadim Chugunov <vadimcn at gmail.com> >>>>> wrote: >>>>> >>>>>> FYI - this commit broke LLVM build using [[ >>>>>> http://stackoverflow.com/questions/13212342/whats-the-difference-between-thread-posixs-and-thread-win32-in-gcc-port-of-windo >>>>>> | win32 threads ]] flavor of the mingw toolchain. I am getting [[ >>>>>> http://stackoverflow.com/questions/14191566/c-mutex-in-namespace-std-does-not-name-a-type >>>>>> | error: 'recursive_mutex' in namespace 'std' does not name a type ]]. >>>>>> Not sure if this would be considered a problem for LLVM... >>>>>> >>>>>> http://reviews.llvm.org/D4196 >>>>>> >>>>>> >>>>>> >>>>> >>>> >>> >>> _______________________________________________ >>> LLVM Developers mailing list >>> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >>> >>> >> >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140620/09669b65/attachment.html>
Zachary Turner
2014-Jun-20 18:14 UTC
[LLVMdev] [PATCH] Replace the Execution Engine's mutex with std::recursive_mutex
Sorry, I mean only disable this for THREADS-WIN32, not threads-posix. On Fri, Jun 20, 2014 at 11:14 AM, Zachary Turner <zturner at google.com> wrote:> #2 is better if we can detect threads-win32 vs threads-posix on MinGW, and > only disable this for threads-posix. We can check for > _GLIBCXX_HAS_GTHREADS, but that seems somewhat hackish, so I wonder if > there's a better way. > > To handle the switching, I guess we'll have to go back to the original > option of having llvm::mutex, llvm::recursive_mutex, etc, and then > conditionally typedefing them. Kinda sucks, but still better than getting > rid of it entirely. > > > On Fri, Jun 20, 2014 at 11:09 AM, Reid Kleckner <rnk at google.com> wrote: > >> OK, sounds like we're screwed. >> >> There's two options: >> 1. Revert and give up on C++11 threading libraries for now. >> 2. Do what Eric suggests. Move all the mutex usage under #ifdef >> LLVM_ENABLE_THREADS, and disable LLVM_ENABLE_THREADS by default on MinGW. >> MinGW plus LLVM_ENABLE_THREADS would become unsupported. >> >> Do people have objections to 2? I don't really like it either. >> >> >> On Fri, Jun 20, 2014 at 10:33 AM, Yaron Keren <yaron.keren at gmail.com> >> wrote: >> >>> The whole "mutex" and "shared_mutex" files are #ifdef >>> _GLIBCXX_HAS_GTHREADS so if no _GLIBCXX_HAS_GTHREADS there are no mutexes >>> and no call_once. thread lives in "thread" which is also #ifdef >>> _GLIBCXX_HAS_GTHREADS. >>> "condition_variable" and "future" are the same. >>> >>> I have tested gcc 4.8.2 predefines and _GLIBCXX_HAS_GTHREADS isn't >>> there nor it is defined anywhere with the win32 version. I have also >>> compiled a small test and indeed it failed with >>> >>> a.cpp:4:3: error: 'mutex' is not a member of 'std'. >>> >>> Just for fun, I tried to compile it with -D_GLIBCXX_HAS_GTHREADS but >>> then it failed on bunch of other errors starting with >>> >>> error: '__gthread_time_t' was not declared in this scope >>> >>> so gthreads isn't there. >>> >>> As to popularity, compare the download graphs for 32 bit: >>> >>> >>> http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win32/Personal%20Builds/mingw-builds/4.9.0/ >>> >>> and 64 bit: >>> >>> >>> http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win64/Personal%20Builds/mingw-builds/4.9.0/ >>> >>> in 32 bit the posix version rules, whereas in 64 bit it is a close >>> winner. If you go back to 4.8.2 the pattern is similar. >>> >>> The win32 version does not support anything thread-related so it's not >>> C++11 compliant? >>> >>> Yaron >>> >>> >>> >>> 2014-06-20 19:55 GMT+03:00 Reid Kleckner <rnk at google.com>: >>> >>>> It sounds like this version of libstdc++ doesn't support >>>> std::recursive_mutex from C++11. This is really unfortunate, because we >>>> were hoping that moving to C++11 would allow us to use standard, portable >>>> threading primitives. >>>> >>>> Does this version of MinGW have any C++11 threading support? Is it >>>> just recursive_mutex that is missing, or do we have to avoid std::mutex, >>>> std::call_once, etc? lld has been using all of these things for some time >>>> now, and in theory we have the same baseline toolchain requirements. >>>> >>>> If it's just std::recursive_mutex, how long do you think it would take >>>> to implement that for mingw's libstdc++? >>>> >>>> Do you have a sense of which version of mingw is more popular, the >>>> pthreads variant or the win32 threads variant? If the overwhelming >>>> majority use the win32 threads variant, I don't think we can break it. >>>> >>>> >>>> On Fri, Jun 20, 2014 at 9:49 AM, Zachary Turner <zturner at google.com> >>>> wrote: >>>> >>>>> I kind of feel like we should drop support for this configuration. >>>>> Here are the reasons why: >>>>> >>>>> 1) clang, lld, and other LLVM-based tools already make use of >>>>> std::recursive_mutex and std::mutex, so if those types don't exist in this >>>>> one configuration, we have already (even if inadvertently) made a statement >>>>> that we don't support that configuration. >>>>> >>>>> 2) We chose C++11 as the baseline because all compilers should support >>>>> it. This functionality in particular is pretty egregious to not support, >>>>> considering how simple it is. >>>>> >>>>> 3) Not supporting this configuration does not mean we don't support >>>>> GCC / MinGW, it only means we don't support GCC / MinGW / threads-win32. >>>>> There is still the threads-posix flavor of this platform which works fine >>>>> on Windows. >>>>> >>>>> #3 is a little unfortunate and backwards, since on Windows we should >>>>> be encouraging native Windows implementations of things and discouraging >>>>> posix emulation, but in this case the functionality just isn't implemented. >>>>> >>>>> >>>>> On Fri, Jun 20, 2014 at 9:26 AM, Zachary Turner <zturner at google.com> >>>>> wrote: >>>>> >>>>>> +llvmdev. >>>>>> >>>>>> I find this pretty surprising. Actually, we already use std::mutex >>>>>> and std::recursive_mutex in clang, lld, and other llvm projects, it's just >>>>>> a coincidence that it hadn't been introduced into LLVM until my commits. >>>>>> >>>>>> I'm not sure what the right thing to do here is. If I understand >>>>>> correctly, it seems like in order to encounter this, a) you must be using >>>>>> GCC, b) you must be using the MinGW flavor of GCC, and c) you must be using >>>>>> the threads-win32 flavor of this toolchain. Only if all 3 of those are >>>>>> true, then std::mutex and std::recursive_mutex don't exist. >>>>>> >>>>>> Anybody else have thoughts on whether this necessitates reverting the >>>>>> mutex changes, or whether this toolchain configuration should be supported? >>>>>> >>>>>> >>>>>> On Fri, Jun 20, 2014 at 12:07 AM, Vadim Chugunov <vadimcn at gmail.com> >>>>>> wrote: >>>>>> >>>>>>> FYI - this commit broke LLVM build using [[ >>>>>>> http://stackoverflow.com/questions/13212342/whats-the-difference-between-thread-posixs-and-thread-win32-in-gcc-port-of-windo >>>>>>> | win32 threads ]] flavor of the mingw toolchain. I am getting [[ >>>>>>> http://stackoverflow.com/questions/14191566/c-mutex-in-namespace-std-does-not-name-a-type >>>>>>> | error: 'recursive_mutex' in namespace 'std' does not name a type ]]. >>>>>>> Not sure if this would be considered a problem for LLVM... >>>>>>> >>>>>>> http://reviews.llvm.org/D4196 >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>>> _______________________________________________ >>>> LLVM Developers mailing list >>>> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >>>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >>>> >>>> >>> >> >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140620/5d461cff/attachment.html>
Anton Korobeynikov
2014-Jun-21 13:28 UTC
[LLVMdev] [PATCH] Replace the Execution Engine's mutex with std::recursive_mutex
> Do people have objections to 2? I don't really like it either.Well, at least we can do a configure-time check and error gracefully on unsupported configuration? -- With best regards, Anton Korobeynikov Faculty of Mathematics and Mechanics, Saint Petersburg State University
Chandler Carruth
2014-Jun-21 13:56 UTC
[LLVMdev] [PATCH] Replace the Execution Engine's mutex with std::recursive_mutex
On Sat, Jun 21, 2014 at 2:28 PM, Anton Korobeynikov <anton at korobeynikov.info> wrote:> Well, at least we can do a configure-time check and error gracefully > on unsupported configuration? >Regardless of which direction, yes,. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140621/6ab67a23/attachment.html>
Seemingly Similar Threads
- [LLVMdev] [PATCH] Replace the Execution Engine's mutex with std::recursive_mutex
- [LLVMdev] [PATCH] Replace the Execution Engine's mutex with std::recursive_mutex
- [LLVMdev] [PATCH] Replace the Execution Engine's mutex with std::recursive_mutex
- [LLVMdev] Multi-threading and mutexes in LLVM
- [LLVMdev] Use of Vectored Exception Handlers for crash recovery