meganz/mingw-std-threads

Standard threads implementation currently still missing on MinGW GCC on Windows

mingw-std-threads

Implementation of standard C++11 threading classes, which are currently still missing on MinGW GCC.

Target Windows version

This implementation should work with Windows XP (regardless of service pack), or newer. The library automatically detects the version of Windows that is being targeted (at compile time), and selects an implementation that takes advantage of available Windows features. In MinGW GCC, the target Windows version may optionally be selected by the command-line option -D _WIN32_WINNT=.... Use 0x0600 for Windows Vista, or 0x0601 for Windows 7. See "Modifying WINVER and _WIN32_WINNT" for more details.

Usage

This is a header-only library. To use, just include the corresponding mingw.xxx.h file, where xxx would be the name of the standard header that you would normally include.

For example, #include "mingw.thread.h" replaces #include <thread>.

A CMakeLists.txt has also been provided. You can add it to your project by using add_subdirectory(), and then this library can be added as your targets' dependency by using target_link_libraries(YOUR_TARGET PRIVATE mingw_stdthreads). By default it just adds a include path, allowing you to include headers using angle brackets (for example #include <mingw.thread.h>). But you can also provide options to let it generate "std-like" headers (see next paragraph).

Using "std-like" headers

Probably you don't really want to replace all your includes from #include <header> to #include "mingw.header.h". So if you are using GCC or clang, here are some ways to make you happy :)

With CMake, you just need to turn on the option MINGW_STDTHREADS_GENERATE_STDHEADERS before adding mingw-stdthreads, something like this:

option(MINGW_STDTHREADS_GENERATE_STDHEADERS "" ON)
add_subdirectory(mingw_stdthreads)
target_link_libraries(${TARGET} PRIVATE mingw_stdthreads)

When CMake generates project files, headers named in the "standard header" way will be generated and added to your include path. Then you can avoid stuffs like mingw.thread.h, and keep using #include <thread> like always. In addition, MINGW_STDTHREADS_GENERATED_STDHEADERS will be defined, you can use this macro to check if those generated headers are actually available.

If you aren't using CMake, you can use one of the three scripts inside utility_scripts directory to manually generate those "std-like" headers. Note that this requires Microsoft Power Shell, so if you are cross-compiling, you would need to install Power Shell.

Compatibility

This code has been tested to work with MinGW-w64 5.3.0, but should work with any other MinGW version that has the std threading classes missing, has C++11 support for lambda functions, variadic templates, and has working mutex helper classes in <mutex>.

Switching from the win32-pthread based implementation

It seems that recent versions of MinGW-w64 include a Win32 port of pthreads, and have the std::thread, std::mutex, etc. classes implemented and working based on that compatibility layer.

You could use the built-in pthread implementation of Mingw by using the posix compiler, eg: x86_64-w64-mingw32-g++-posix (for Windows 64-bit).

That is a somewhat heavier implementation, as it relies on an abstraction layer, so you may still want to use this implementation for efficiency purposes. Unfortunately you can't use this library standalone and independent of the system <mutex> headers, as it relies on those headers for std::unique_lock and other non-trivial utility classes. In that case you will need to edit the c++-config.h file of your MinGW setup and comment out the definition of _GLIBCXX_HAS_GTHREADS. This will cause the system headers not to define the actual thread, mutex, etc. classes, but still define the necessary utility classes.

Why MinGW has no threading classes

It seems that for cross-platform threading implementation, the GCC standard library relies on the gthreads/pthreads library. If this library is not available, as is the case with MinGW, the classes std::thread, std::mutex, std::condition_variable are not defined. However, various usable helper classes are still defined in the system headers. Hence, this implementation does not re-define them, and instead includes those headers.

mingw-std-threads's Issues

Trouble compiling with gcc 11.1

Hi,

I have been trying to compile this code from boost 1.76.0 with mingw-w64 gcc 11:

/*  Copyright 2020 Rene Rivera
 *  Distributed under the Boost Software License, Version 1.0.
 *  (See accompanying file LICENSE_1_0.txt or http://www.boost.org/LICENSE_1_0.txt)
 */

/*
This program is a compile test for support of C++11. If it compiles
successfully some key parts of C++11 the B2 engine requires are
available. This is used by the build script to guess and check the
compiler to build the engine with.
*/

// Some headers we depend on..
#include <thread>


int main()
{
    // Check for basic thread calls.
    { auto _ = std::thread::hardware_concurrency(); }
}

I get the following error with gcc 11.1, but not with gcc 10.3 or other earlier gcc 10:

In file included from C:/mingw-gcc-11.1.0/i686-1110-win32-sjlj-rt_v9-rev0/mingw32/opt/include/mingw-std-threads/thread:3,
                 from check_cxx11.cpp:14:
C:/mingw-gcc-11.1.0/i686-1110-win32-sjlj-rt_v9-rev0/mingw32/opt/include/mingw-std-threads/mingw.thread.h:330:24: error: 'class mingw_stdthread::thread' conflicts with a previous declaration
  330 | using mingw_stdthread::thread;
      |                        ^~~~~~
In file included from C:/mingw-gcc-11.1.0/i686-1110-win32-sjlj-rt_v9-rev0/mingw32/lib/gcc/i686-w64-mingw32/11.1.0/include/c++/thread:43,
                 from C:/mingw-gcc-11.1.0/i686-1110-win32-sjlj-rt_v9-rev0/mingw32/opt/include/mingw-std-threads/thread:2,
                 from check_cxx11.cpp:14:
C:/mingw-gcc-11.1.0/i686-1110-win32-sjlj-rt_v9-rev0/mingw32/lib/gcc/i686-w64-mingw32/11.1.0/include/c++/bits/std_thread.h:62:9: note: previous declaration 'class std::thread'
   62 |   class thread
      |         ^~~~~~

It seems this error is new to gcc 11. Commenting out using mingw_stdthread::thread on line 330 of mingw.thread.h allows me to get past this error, but causes downstream errors when building boost as one can expect.

I'll say that I m surprised that it appears no one else has seen this issue with mingw-w64 gcc 11. I'm wondering if this is on my end. I build my own gcc with scripts from mingw-builds.

Thank you for making mingw-std-threads available and also for any help that you can provide on this issue.

Leaked thread handle

Shouldn't there be CloseHandle(mHandle) in detach() function ?
Now thread handle is never closed.

Problem with codec Lepton

I know that the codec will not compile under Windows. This is an unfinished project.
However, it bothers me a error in ioutil.cc.

std::thread discard_stderr(std::bind(&discard_stderr, retval.pipe_stderr));
discard_stderr.detach();

Fails to build when tarrgeting WinRT / Windows Store apps

$ cat test.cpp 
#include "mingw.thread.h"
int main() {
    return 0;
}
$ i686-w64-mingw32-g++-win32 -DWINAPI_FAMILY=0x2 -D_WIN32_WINNT=0x0602 test.cpp 
In file included from test.cpp:1:0:
mingw.thread.h: In static member function ‘static unsigned int mingw_stdthread::thread::_hardware_concurrency_helper()’:
mingw.thread.h:266:9: error: ‘::GetSystemInfo’ has not been declared
         ::GetSystemInfo(&sysinfo);
         ^~

GetSystemInfo() is not available for WINAPI_FAMILY=0x2.
GetNativeSystemInfo() is however available and provides the identical information, and also works when targeting standard desktop.

Please replace GetSystemInfo with GetNativeSystemInfo.

Note that GetNativeSystemInfo requires _WIN32_WINNT >= 0x501 (>= Windows XP). Thus, if mingw-std-threads still wants to support pre Windows XP, this requires an #if.

HOW TO FUCKING COMPILE/MAKE A FUCKING COMPILED RELEASE LAZY ASS

Upstream into MinGW?

Is there any effort being made to upstream this into MinGW?

error: ‘shared_lock’ has not been declared in ‘std’

/sources/extern/openxr/build/OpenXR-SDK-release-1.0.22/mingw_stdthreads/mingw.shared_mutex.h:306:12: error: ‘shared_lock’ has not been declared in ‘std’
  306 | using std::shared_lock;

I tried upgrading mingw (version 10) but it's not working.

The offending line is mingw_stdthreads/mingw.shared_mutex.h:306

#if __cplusplus >= 201402L
using std::shared_lock;
#else

This means c++14 or higher is used but std::shared_lock does not exist. What can be done to fix this?

Problem with std::packaged_task in c++17

I wanted to compile an htjpeg2000 grok which uses the ThreadPool library.
https://github.com/progschj/ThreadPool
I can't compile the save.

    auto task = std::make_shared< std::packaged_task<return_type()> >(
            std::bind(std::forward<F>(f), std::forward<Args>(args)...)
        );

or

    auto task = std::shared_ptr< std::packaged_task<return_type()> >(
                 new std::packaged_task<return_type()>(std::bind(std::forward<F>(f), std::forward<Args>(args)...))
        );

Problem with mutex.h

I don't know how to describe it. I mean that some programs don't tolerate <windows.h> and thus are incompatible with some typedef functions of the HALF, FLOAT or some cann't tolerate at all. Is there any idea to bypass this problem?
Recently, I have a problem compiling a new codec VVC with WPP PARALLEISM functions.
https://vcgit.hhi.fraunhofer.de/jvet/VVCSoftware_VTM
msg((MsgLevel) ERROR

Compile Error using std::thread and objects (this)

I can't generate a std::thread which works on an object (extra argument this).
std::thread t(&Hello::print, this);
The following program runs fine under linux, however we get an error using a 4.9.3 gcc:

mingw.thread.h:67:11: error: must use '.*' or '->*' to call pointer-to-member function in '((mingw_stdthread::detail::ThreadFuncCall<void (Hello::*)(), Hello*>*)this)->mingw_stdthread::detail::ThreadFuncCall<void (Hello::*)(), Hello*>::mFunc (...)', e.g. '(... ->* ((mingw_stdthread::detail::ThreadFuncCall<void (Hello::*)(), Hello*>*)this)->mingw_stdthread::detail::ThreadFuncCall<void (Hello::*)(), Hello*>::mFunc) (...)' mFunc(std::get<S>(std::forward<Tuple>(mArgs)) ...);

#include <iostream>
#include <thread>
#include <mingw.thread.h>
struct Hello {
	int val;
	Hello(int val_): val(val_){
		std::thread t(&Hello::print, this);
		t.join();
	};
	void print () {
		std::cout << "Hello " << val << std::endl;
	}

};
int main(int argc, char **argv) {
	Hello h(1);
}

The wait_for method of std::future is problem

The wait_for method of std::future cannot return over time, and the time parameter is invalid

Missing std::once_flag

I've tried incorporating your headers into a recent mingw build, and it works beautifully, but I noticed one missing construct that the upstream mutex header has (based on gthreads), but your implementation misses. It's the std::once_flag. Any pointers on how I could work around this issue (beside reworking the client code not to use it :P)? Thanks!

Missing license

I can't find a license anywhere, and this prevents me from using any of the code here. At the very least you should provide a LICENSE file. If you just want anyone to be able to use the code, then make it public domain via unlicense.

AcquireSRWLockExclusive was not declared

I'm trying to port a multithreading program to Windows 10. It works fine in Linux and DragonFly BSD, and I got it to compile, run, and show its window in Windows. But attempting to load a file (which is done by a thread) resulted in nothing happening. I ran it in gdb and found that Qt's threads were apparently acting normally, but mine were not running the thread function. I modified it to use mingw-std-threads; after I fixed the namespace issues, these compile errors remain:

In file included from C:/Users/phma/src/perfecttin/threads.h:26,
                 from C:/Users/phma/src/perfecttin/gui.cpp:30:
C:/Users/phma/src/mingw-std-threads/mingw.mutex.h: In member function 'void mingw_stdthread::windows7::mutex::lock()':
C:/Users/phma/src/mingw-std-threads/mingw.mutex.h:179:9: error: 'AcquireSRWLockExclusive' was not declared in this scope
         AcquireSRWLockExclusive(&mHandle);
         ^~~~~~~~~~~~~~~~~~~~~~~
C:/Users/phma/src/mingw-std-threads/mingw.mutex.h:179:9: note: suggested alternative: 'RpcSsContextLockExclusive'
         AcquireSRWLockExclusive(&mHandle);
         ^~~~~~~~~~~~~~~~~~~~~~~
         RpcSsContextLockExclusive
C:/Users/phma/src/mingw-std-threads/mingw.mutex.h: In member function 'void mingw_stdthread::windows7::mutex::unlock()':
C:/Users/phma/src/mingw-std-threads/mingw.mutex.h:189:9: error: 'ReleaseSRWLockExclusive' was not declared in this scope
         ReleaseSRWLockExclusive(&mHandle);
         ^~~~~~~~~~~~~~~~~~~~~~~
C:/Users/phma/src/mingw-std-threads/mingw.mutex.h:189:9: note: suggested alternative: 'RpcSsContextLockExclusive'
         ReleaseSRWLockExclusive(&mHandle);
         ^~~~~~~~~~~~~~~~~~~~~~~
         RpcSsContextLockExclusive
C:/Users/phma/src/mingw-std-threads/mingw.mutex.h: In member function 'bool mingw_stdthread::windows7::mutex::try_lock()':
C:/Users/phma/src/mingw-std-threads/mingw.mutex.h:198:20: error: 'TryAcquireSRWLockExclusive' was not declared in this scope
         BOOL ret = TryAcquireSRWLockExclusive(&mHandle);
                    ^~~~~~~~~~~~~~~~~~~~~~~~~~
C:/Users/phma/src/mingw-std-threads/mingw.mutex.h:198:20: note: suggested alternative: 'RpcSsContextLockExclusive'
         BOOL ret = TryAcquireSRWLockExclusive(&mHandle);
                    ^~~~~~~~~~~~~~~~~~~~~~~~~~
                    RpcSsContextLockExclusive
In file included from C:/Users/phma/src/perfecttin/threads.h:27,
                 from C:/Users/phma/src/perfecttin/gui.cpp:30:
C:/Users/phma/src/mingw-std-threads/mingw.shared_mutex.h: In member function 'void mingw_stdthread::windows7::shared_mutex::lock_shared()':
C:/Users/phma/src/mingw-std-threads/mingw.shared_mutex.h:223:9: error: 'AcquireSRWLockShared' was not declared in this scope
         AcquireSRWLockShared(native_handle());
         ^~~~~~~~~~~~~~~~~~~~
C:/Users/phma/src/mingw-std-threads/mingw.shared_mutex.h:223:9: note: suggested alternative: 'RpcSsContextLockShared'
         AcquireSRWLockShared(native_handle());
         ^~~~~~~~~~~~~~~~~~~~
         RpcSsContextLockShared
C:/Users/phma/src/mingw-std-threads/mingw.shared_mutex.h: In member function 'void mingw_stdthread::windows7::shared_mutex::unlock_shared()':
C:/Users/phma/src/mingw-std-threads/mingw.shared_mutex.h:228:9: error: 'ReleaseSRWLockShared' was not declared in this scope
         ReleaseSRWLockShared(native_handle());
         ^~~~~~~~~~~~~~~~~~~~
C:/Users/phma/src/mingw-std-threads/mingw.shared_mutex.h:228:9: note: suggested alternative: 'ReleaseSemaphore'
         ReleaseSRWLockShared(native_handle());
         ^~~~~~~~~~~~~~~~~~~~
         ReleaseSemaphore
C:/Users/phma/src/mingw-std-threads/mingw.shared_mutex.h: In member function 'bool mingw_stdthread::windows7::shared_mutex::try_lock_shared()':
C:/Users/phma/src/mingw-std-threads/mingw.shared_mutex.h:235:16: error: 'TryAcquireSRWLockShared' was not declared in this scope
         return TryAcquireSRWLockShared(native_handle()) != 0;
                ^~~~~~~~~~~~~~~~~~~~~~~
[4/5] Building CXX object CMakeFiles/perfecttin-gui.dir/mainwindow.cpp.obj

I'm using these versions:

cmake version 3.14.5
gcc.exe (x86_64-posix-seh-rev0, Built by MinGW-W64 project) 8.1.0

tests.cpp file not working

I downloaded and ran tests.cpp file in codeblocks, and I get a bunch of error, first being '::GetNativeSystemInfo has not been declared'. I suppose I have wrong mingw version, since this implementation of standard threads doesnt work out of the box?

Does not work with std::unique_ptr

Need to implement Deleter class for std::thread

Reference: http://en.cppreference.com/w/cpp/memory/unique_ptr

#include <cstdio>
#include <memory>
#include <thread>

#include "mingw.thread.h"

int main() {
    std::unique_ptr<std::thread> p([&]() {
        printf("Hello World!\n");
    });
    p->join()
    return 0;
}

C++20 feature: jthread

Issue tracking implementation of jthreads, introduced in C++20.

See jthread on cppreference.com.

timed_mutex broken?

It seems that timed_mutex doesn't have a constructor, much less one that's public.

Mutex, timed_mutex, and call_once are not fully standard-compliant

Certain parts of the existing classes are not fully standard compliant. This comment lists them, lest we forget.

• Classes mutex and timed_mutex do not satisfy the StandardLayoutType concept. (Will be fixed by #36)
  • Adding the variable mOwnerThread violates the requirement for the inheritance tree to have only one class that defines non-static members.
  • Compliance is practical, but possibly undesired.
    • Recursively locking a non-recursive mutex is undefined behavior.
    • Compliance would either remove error-checking code or bloat the recursive mutex classes.
• Class mutex must have a constexpr constructor, but will not if both NDEBUG and STDMUTEX_NO_RECURSION_CHECKS are defined. (Will be fixed by #36)
  • Causes a compiler error to be thrown by once_flag.
    • If necessary, once_flag and call_once can be rewritten to use only an atomic_char and its compare_exchange_weak function, rather than depending on the mutex implementation. Efficiency of this implementation could be improved in Windows 8 by using WaitOnAddress. See #36
  • Compliance is impractical for Windows XP and Windows Vista.
    • Static initialization is not supported for CRITICAL_SECTION objects.
  • Compliance is possible for Windows 7.
    • Using a Slim Reader/Writer (SRW) lock, as in shared_mutex, would allow static initialization from a compile-time constant.
• Function call_once, and the thread constructor, do not behave as if calling invoke. In particular, member function pointers are not handled correctly. Member data members are less of a concern in this context, but still must be handled for standard compliance.
  • Compliance is possible.
    • If compiling for C++17, simply use invoke.
    • If compiling for C++11, use a helper class and template specialization to define an equivalent of invoke early.

Building GCC 9.3 meet some error

Hi,
Do you have some time to help me to solve the problem with building gcc 9.3 on windows?
Thanks.

Here was my information during Build gcc, how it makes, I'm my best to solve the error, but it's no work

My configure is

../gcc-9.3.0/configure --host=x86_64-w64-mingw32 --build=x86_64-w64-mingw32 --target=x86_64-w64-mingw32 --prefix=/P/Efreets/gcc930/ --with-sysroot=/P/Efreets/gcc930/ --enable-languages=c,lto,c++,fortran --enable-lto --enable-static --disable-symvers --disable-shared --enable-threads=posix --enable-sjlj-exceptions --with-system-zlib --with-gmp=/P/Efreets/gmp620 --with-mpfr=/P/Efreets/mpfr402 --with-mpc=/P/Efreets/mpc110 --with-isl=/P/Efreets/isl221 --with-zstd=/P/Efreets/zstd144

It's meet this error

[ -f stage_final ] || echo stage3 > stage_final
make[1]: Entering directory 'P:/gcc930/gcc-9.3.0/Build'
make[2]: Entering directory 'P:/gcc930/gcc-9.3.0/Build'
make[3]: Entering directory 'P:/gcc930/gcc-9.3.0/Build'
rm -f stage_current
make[3]: Leaving directory 'P:/gcc930/gcc-9.3.0/Build'
make[2]: Leaving directory 'P:/gcc930/gcc-9.3.0/Build'
make[2]: Entering directory 'P:/gcc930/gcc-9.3.0/Build'
/usr/bin/sh: -c:行6: unexpected EOF while looking for matching `''
/usr/bin/sh: -c:行7: syntax error: unexpected end of file
make[2]: *** [Makefile:11206: all-stage1-libiberty] Error 1
make[2]: Leaving directory 'P:/gcc930/gcc-9.3.0/Build'
make[1]: *** [Makefile:21113: stage1-bubble] Error 2
make[1]: Leaving directory 'P:/gcc930/gcc-9.3.0/Build'
make: *** [Makefile:1003: all] Error 2

And this is the error line in MakeFile

I think error line in right, but I can't solve the problem, could you help me ?

I can't thank you so much, I need you help, Waiting message.

yours sincerely

synchapi.h: No such file or directory

Hi, I'm getting a synchapi.h: No such file or directory error while trying to use <mingw.thread.h> under Windows 10. This is the output from gcc -v:

gcc -v
Using built-in specs.
COLLECT_GCC=C:\Program Files (x86)\mingw-w64\i686-8.1.0-posix-dwarf-rt_v6-rev0\mingw32\bin\gcc.exe
COLLECT_LTO_WRAPPER=C:/Program\ Files\ (x86)/mingw-w64/i686-8.1.0-posix-dwarf-rt_v6-rev0/mingw32/bin/../libexec/gcc/i686-w64-mingw32/8.1.0/lto-wrapper.exe
Target: i686-w64-mingw32
Configured with: ../../../src/gcc-8.1.0/configure --host=i686-w64-mingw32 --build=i686-w64-mingw32 --target=i686-w64-mingw32 --prefix=/mingw32 --with-sysroot=/c/mingw810/i686-810-posix-dwarf-rt_v6-rev0/mingw32 --enable-shared --enable-static --disable-multilib --enable-languages=c,c++,fortran,lto --enable-libstdcxx-time=yes --enable-threads=posix --enable-libgomp --enable-libatomic --enable-lto --enable-graphite --enable-checking=release --enable-fully-dynamic-string --enable-version-specific-runtime-libs --disable-sjlj-exceptions --with-dwarf2 --disable-libstdcxx-pch --disable-libstdcxx-debug --enable-bootstrap
--disable-rpath --disable-win32-registry --disable-nls --disable-werror --disable-symvers --with-gnu-as --with-gnu-ld --with-arch=i686 --with-tune=generic --with-libiconv --with-system-zlib --with-gmp=/c/mingw810/prerequisites/i686-w64-mingw32-static --with-mpfr=/c/mingw810/prerequisites/i686-w64-mingw32-static --with-mpc=/c/mingw810/prerequisites/i686-w64-mingw32-static --with-isl=/c/mingw810/prerequisites/i686-w64-mingw32-static --with-pkgversion='i686-posix-dwarf-rev0, Built by MinGW-W64 project' --with-bugurl=https://sourceforge.net/projects/mingw-w64 CFLAGS='-O2 -pipe -fno-ident -I/c/mingw810/i686-810-posix-dwarf-rt_v6-rev0/mingw32/opt/include -I/c/mingw810/prerequisites/i686-zlib-static/include -I/c/mingw810/prerequisites/i686-w64-mingw32-static/include' CXXFLAGS='-O2 -pipe -fno-ident -I/c/mingw810/i686-810-posix-dwarf-rt_v6-rev0/mingw32/opt/include -I/c/mingw810/prerequisites/i686-zlib-static/include -I/c/mingw810/prerequisites/i686-w64-mingw32-static/include' CPPFLAGS=' -I/c/mingw810/i686-810-posix-dwarf-rt_v6-rev0/mingw32/opt/include -I/c/mingw810/prerequisites/i686-zlib-static/include -I/c/mingw810/prerequisites/i686-w64-mingw32-static/include' LDFLAGS='-pipe -fno-ident -L/c/mingw810/i686-810-posix-dwarf-rt_v6-rev0/mingw32/opt/lib -L/c/mingw810/prerequisites/i686-zlib-static/lib -L/c/mingw810/prerequisites/i686-w64-mingw32-static/lib -Wl,--large-address-aware'
Thread model: posix
gcc version 8.1.0 (i686-posix-dwarf-rev0, Built by MinGW-W64 project)

It also happens with another version of gcc:

Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=c:/mingw/bin/../libexec/gcc/mingw32/6.3.0/lto-wrapper.exe
Target: mingw32
Configured with: ../src/gcc-6.3.0/configure --build=x86_64-pc-linux-gnu --host=mingw32 --target=mingw32 --with-gmp=/mingw --with-mpfr --with-mpc=/mingw --with-isl=/mingw --prefix=/mingw --disable-win32-registry --with-arch=i586 --with-tune=generic --enable-languages=c,c++,objc,obj-c++,fortran,ada --with-pkgversion='MinGW.org GCC-6.3.0-1' --enable-static --enable-shared --enable-threads --with-dwarf2 --disable-sjlj-exceptions --enable-version-specific-runtime-libs --with-libiconv-prefix=/mingw --with-libintl-prefix=/mingw --enable-libstdcxx-debug --enable-libgomp --disable-libvtv --enable-nls
Thread model: win32
gcc version 6.3.0 (MinGW.org GCC-6.3.0-1)

Thoughts?

C++20 feature: counting_semaphore and binary_semaphore

Issue tracking implementation of counting_semaphores, introduced in C++20.

See counting_semaphore and binary_semaphore on cppreference.com.

Potential implementations:

• Semaphore objects in Windows XP and above.
• WaitOnAddress in Windows 8 and above. Note: Ensuring that Windows has access to the correct address will require using Windows' Compare-Exchange functions on a regular integer, rather than the standard C++ atomics.

Inline functions

Wouldn't it be nicer to have the functions defined by inline? Otherwise, having multiple .cpp files that all include the same, say "mingw.thread.h", file, the one definition rule isn't obeyed.

std::thread::hardware_concurrency() always returns 1

I don't think it is a good idea to always return 1, since:

• It's not true on pretty much any modern hardware.
• The spec says: If this value is not computable or well defined an implementation should return 0.

Addition mingw-std-pthreads

I recently found addition pthreads for win64 C++ under mutex / thread / condition_variable
It doesn't work yet with libgomp under MinGW. Not all functions, but I think it can be applied to free github projects soon.
https://github.com/ultravideo/ThreadWrapper

Maybe it will be useful to someone

Need correction for std::future (and probably std::shared_mutex)

Currently, std::future class doesn’t work as all of its implementation is hidden under _GLIBCXX_HAS_GTHREADS macro. g++ generates error: invalid use of incomplete type 'class std::future'

Releasing on Github

Hello,

I would like to know if you are planning to release a fixed version of this library? It'd be easier to package using specific tags rather than commit hashes as version numbers.

How is this compared to mcfgthread?

https://github.com/lhmouse/mcfgthread/

Assignment allowed for std::mutex and then crashes

This code compiles without error:

#include <mutex>
struct S { std::mutex a; };

int main()
{
  S s, t;
    s = t;
}

and sometimes crashes at runtime with access violation because DeleteCriticalSection is called twice on the same critical section.

The same code fails to compile in a unix-based installation of g++, saying that S has a deleted operator= because std::mutex has a deleted operator=.

As a workaround, I added void operator=(_NonRecursiveMutex<B> const &) = delete; to mingw.mutex.h, just after the existing line _NonRecursiveMutex (const _NonRecursiveMutex<B>&) = delete;. But I have not investigated as to whether other mutexes or sync objects had the same problem also.

C++20 feature: latch

Issue tracking implementation of latches, introduced in C++20.

See latch on cppreference.com.

Potential implementations:

• Atomic-based. Portable, but does not cause threads to sleep when blocking.
• Atomic variable & condition_variable. Mostly efficient. May have issues with cost of construction / destruction.
• Atomic & WaitOnAddress. Requires Windows 8, but should have minimal overhead.

error: 'SRWLOCK_INIT' was not declared in this scope

I'm trying to make an async function for my C++ program but i got this:

====================[ Build | all | Debug ]=====================================
"G:\CLion 2021.2\bin\cmake\win\bin\cmake.exe" --build C:\Users\minec\CLionProjects\untitled1\cmake-build-debug --target all -- -j 3
Scanning dependencies of target untitled1
[ 33%] Building CXX object CMakeFiles/untitled1.dir/main.cpp.obj
In file included from C:/Users/minec/CLionProjects/untitled1/cmake-build-debug/mingw_stdthreads/cmake_stdheaders_generator/cmake_stdheaders_generator/mutex:10:0,
                 from c:\mingw\include\boost\beast\websocket\detail\prng.ipp:18,
                 from c:\mingw\include\boost\beast\websocket\detail\prng.hpp:47,
                 from c:\mingw\include\boost\beast\websocket\detail\hybi13.ipp:15,
                 from c:\mingw\include\boost\beast\websocket\detail\hybi13.hpp:45,
                 from c:\mingw\include\boost\beast\websocket\stream.hpp:19,
                 from c:\mingw\include\boost\beast\websocket.hpp:18,
                 from C:\Users\minec\CLionProjects\untitled1\main.cpp:19:
C:/Users/minec/CLionProjects/untitled1/mingw_stdthreads/mingw.mutex.h:49:17: note: #pragma message: The Windows API that MinGW-w32 provides is not fully compatible with Microsoft's API. We'll try to work around this, but we can make no guarantees. This problem does not exist in MinGW-w64.
 #pragma message "The Windows API that MinGW-w32 provides is not fully compatible\
                 ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~                                                                                                                              
In file included from C:/Users/minec/CLionProjects/untitled1/cmake-build-debug/mingw_stdthreads/cmake_stdheaders_generator/cmake_stdheaders_generator/mutex:10:0,
                 from c:\mingw\include\boost\beast\websocket\detail\prng.ipp:18,
                 from c:\mingw\include\boost\beast\websocket\detail\prng.hpp:47,
                 from c:\mingw\include\boost\beast\websocket\detail\hybi13.ipp:15,
                 from c:\mingw\include\boost\beast\websocket\detail\hybi13.hpp:45,
                 from c:\mingw\include\boost\beast\websocket\stream.hpp:19,
                 from c:\mingw\include\boost\beast\websocket.hpp:18,
                 from C:\Users\minec\CLionProjects\untitled1\main.cpp:19:
C:/Users/minec/CLionProjects/untitled1/mingw_stdthreads/mingw.mutex.h: In constructor 'constexpr mingw_stdthread::windows7::mutex::mutex()':
C:/Users/minec/CLionProjects/untitled1/mingw_stdthreads/mingw.mutex.h:176:43: error: 'SRWLOCK_INIT' was not declared in this scope
     constexpr mutex () noexcept : mHandle(SRWLOCK_INIT) { }
                                           ^~~~~~~~~~~~
In file included from C:/Users/minec/CLionProjects/untitled1/cmake-build-debug/mingw_stdthreads/cmake_stdheaders_generator/cmake_stdheaders_generator/thread:10:0,
                 from C:\Users\minec\CLionProjects\untitled1\main.cpp:25:
C:/Users/minec/CLionProjects/untitled1/mingw_stdthreads/mingw.thread.h: At global scope:
C:/Users/minec/CLionProjects/untitled1/mingw_stdthreads/mingw.thread.h:44:17: note: #pragma message: The Windows API that MinGW-w32 provides is not fully compatible with Microsoft's API. We'll try to work around this, but we can make no guarantees. This problem does not exist in MinGW-w64.
 #pragma message "The Windows API that MinGW-w32 provides is not fully compatible\
                 ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~                                                                                                                              
mingw32-make.exe[2]: *** [CMakeFiles/untitled1.dir/main.cpp.obj] Error 1
mingw32-make.exe[1]: *** [CMakeFiles/untitled1.dir/all] Error 2
CMakeFiles\untitled1.dir\build.make:71: recipe for target 'CMakeFiles/untitled1.dir/main.cpp.obj' failed
CMakeFiles\Makefile2:113: recipe for target 'CMakeFiles/untitled1.dir/all' failed
Makefile:89: recipe for target 'all' failed
mingw32-make.exe: *** [all] Error 2

#define _WIN32_WINNT 0x0602
#define WINVER 0x0602

C++20 feature: barrier

Issue tracking implementation of barrieres, introduced in C++20.

See barrier and experimental::barrier on cppreference.com.

Question about the new definition std :: jthread

How different is the std::thread from std::jthread?
Does it make sense to change definitions for c++20?
Is std::jthread only under c++20?
I was able to compile std::jthread under c++17. Is it compatible with mingw.thread?
https://github.com/josuttis/jthread

Missing license

Could you please add some license to the project? Is it allowed to be used in open-source software?