llvm dev - Jun 2014 - [LLVMdev] [PATCH] Replace the Execution Engine's mutex with std::recursive_mutex

+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
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20140620/adacdec6/attachment.html>

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
>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20140620/f2f231f4/attachment.html>

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
>>>
>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20140620/30d224dc/attachment.html>

Hi,

On Windows, MinGW is the gcc distribution so a)==b).  The stackoverflow
link above is for 4.7.2 but it's also correct for 4.8.2 and the latest 4.9:
_GLIBCXX_HAS_GTHREADS is not defined in c++config.h in the wIndows threads
dist. so "mutex" does not provide recursive_mutex and mutex.
It's odd since the win32 dist. is shipped with libwinpthread-1.dll so
defining _GLIBCXX_HAS_GTHREADS  may actually work.

I personally build with Visual C++.

Yaron






2014-06-20 19:49 GMT+03:00 Zachary Turner <zturner at google.com>:
> 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/abc254ad/attachment.html>