Despite pthread_mutex, would mutex (#include <mutex>) make pthread safe using C++11?
Please find down an example:
// Creating Server thread
pthread_create(&server_thread, NULL,Server,NULL);
// Creating Client thread
pthread_create(&client_thread, NULL, Client,NULL);
// Wait until client_thread exits
pthread_join( client_thread, NULL);
both Server, and Client call foo().
mutex mut;
void foo (){
mut.lock();
CRITICAL_WRITE();
mut.unlock();
}
It is implementation specific. The C++11 standard libraries I know about (e.g. libstdc++ in GCC 4.9, and probably also libc++ from Clang/LLVM) are practically built above the existing pthreads(7) library on Linux.
Someone could in principle build some C++11 standard library on Linux directly using system calls (e.g. futex(2) -mixed with hand-written assembly code- for mutual exclusion locks), but I know none such C++11 library.
The threads are built on Linux in pthreads above the low-level clone(2) syscall.
So you don't have a formal guarantee, but in practice you are today quite safe (on Linux)
Related
I have created a new thread in my program with CreaThread() function which is present in windows.h and I compiled with with this command gcc myprogram.c but when i started my program it seem that the thread was not started why?i thought that gcc doesn't multithreading can any one help me
gcc supports multi-threading. The support is not limited to ability to call CreateThread function, there are most importantly C memory model, C atomic operations, C thread support library
I am looking to use the __sync_fetch_and_xxx functions for thread safe shared memory access on my Linux application with a beagleboard and gumstix. I can't seem to find the correct header to include. Are these functions only available for kernel development?
Thanks
These are compiler builtins. They are available for user development. You need no header to include, if gcc on your architecture supports them, it will produce correct assembler, if no, then it will produce an error.
I started to use C++11 std::thread (mingw 4.8) so far so good. I ran into a situation with overlapped I/O where sleepEx was used to put the thread in an alertable wait state. This worked quite well, until QueueUserAPC had to be used, which returned an "invalid handle error".
After some searching found out that std::thread uses the pthread library under Windows.
Is there any way to use windows API calls which expect a thread handle with std::thread ?
Or do I need to stick with Windows threads for overlapped I/O ?
To solve your issue, MinGW-w64 winpthreads (the pthreads implementation you are using), just like pthreads-win32, allows you to get the native Win32 thread handle for a pthread:
void * pthread_gethandle (pthread_t t);
Note that this is currently an undocumented function.
The corresponding function in pthreads-win32 is:
HANDLE pthread_getw32threadhandle_np(pthread_t thread);
I'd bet this will make your intermixing of the two work, or at least bring to light some bugs in winpthreads which can be fixed. In the latter case, please report them to MinGW-w64.
If the above returns an invalid handle, your best bet is to ask on the MinGW-w64-public mailing list (subscribe first, otherwise you'll have to wait for manual moderation which is silly).
Is there any way to use windows API calls which expect a thread handle with std::thread ?
No, because the std::thread in your MinGW build isn't implemented in terms of thread handles. Edit: it is, but indirectly, see rubenvb's answer for how to get the native thread handle from a pthread_t, and you should be able to use std::thread::native_handle() to get the pthread_t.
Noone has implemented the necessary support in GCC for the C++11 thread library to use native Windows threads directly.
I had some ideas for a new thead model that would be implemented in terms of native mutexes and condition variables. That would allow you to call std::thread::native_handle() to get the underlying thread handle to use with the Windows API.
I got as far as rebuilding GCC with my changes applied, but couldn't test them. There was almost no interest in my suggestions and no offers to help from any MinGW contributors, so as I'm not a Windows user, and working on Windows and building MinGW was so painful and frustrating, I gave up. I should put my changes online somewhere, so that someone with more patience than me can finish the work one day.
There is already a native win32 implementation of std::thread and sync primitives, see:
https://github.com/meganz/mingw-std-threads
This is a header-only library and works with any version of MinGW that has proper language support for C++11
I'm installing mingw-w64 on Windows and there are two options: win32 threads and posix threads. I know what is the difference between win32 threads and pthreads but I don't understand what is the difference between these two options. I doubt that if I will choose posix threads it will prevent me from calling WinAPI functions like CreateThread.
It seems that this option specify which threading API will be used by some program or library, but by what? By GCC, libstdc++ or by something else?
I found this:
Whats the difference between thread_posixs and thread_win32 in gcc port of windows?
In short, for this version of mingw, the threads-posix release will use the posix API and allow the use of std::thread, and the threads-win32 will use the win32 API, and disable the std::thread part of the standard.
Ok, if I will select win32 threads then std::thread will be unavailable but win32 threads will still be used. But used by what?
GCC comes with a compiler runtime library (libgcc) which it uses for (among other things) providing a low-level OS abstraction for multithreading related functionality in the languages it supports. The most relevant example is libstdc++'s C++11 <thread>, <mutex>, and <future>, which do not have a complete implementation when GCC is built with its internal Win32 threading model. MinGW-w64 provides a winpthreads (a pthreads implementation on top of the Win32 multithreading API) which GCC can then link in to enable all the fancy features.
I must stress this option does not forbid you to write any code you want (it has absolutely NO influence on what API you can call in your code). It only reflects what GCC's runtime libraries (libgcc/libstdc++/...) use for their functionality. The caveat quoted by #James has nothing to do with GCC's internal threading model, but rather with Microsoft's CRT implementation.
To summarize:
posix: enable C++11/C11 multithreading features. Makes libgcc depend on libwinpthreads, so that even if you don't directly call pthreads API, you'll be distributing the winpthreads DLL. There's nothing wrong with distributing one more DLL with your application.
win32: No C++11 multithreading features.
Neither have influence on any user code calling Win32 APIs or pthreads APIs. You can always use both.
Parts of the GCC runtime (the exception handling, in particular) are dependent on the threading model being used. So, if you're using the version of the runtime that was built with POSIX threads, but decide to create threads in your own code with the Win32 APIs, you're likely to have problems at some point.
Even if you're using the Win32 threading version of the runtime you probably shouldn't be calling the Win32 APIs directly. Quoting from the MinGW FAQ:
As MinGW uses the standard Microsoft C runtime library which comes with Windows, you should be careful and use the correct function to generate a new thread. In particular, the CreateThread function will not setup the stack correctly for the C runtime library. You should use _beginthreadex instead, which is (almost) completely compatible with CreateThread.
Note that it is now possible to use some of C++11 std::thread in the win32 threading mode. These header-only adapters worked out of the box for me:
https://github.com/meganz/mingw-std-threads
From the revision history it looks like there is some recent attempt to make this a part of the mingw64 runtime.
#rubenvb answer is fully correct, use the mingw posix compiler if you want to use std::thread, std::mutex, etc. For everybody who is using CMake, here is an example:
set(CMAKE_CXX_STANDARD 17) # or 20 if you want..
set(CMAKE_CXX_STANDARD_REQUIRED ON)
set(THREADS_PREFER_PTHREAD_FLAG ON)
set(TOOLCHAIN_PREFIX x86_64-w64-mingw32)
set(CMAKE_C_COMPILER ${TOOLCHAIN_PREFIX}-gcc-posix)
set(CMAKE_CXX_COMPILER ${TOOLCHAIN_PREFIX}-g++-posix)
set(CMAKE_RC_COMPILER ${TOOLCHAIN_PREFIX}-windres)
set(CMAKE_FIND_ROOT_PATH
/usr/${TOOLCHAIN_PREFIX}
)
Ideal for cross-compiling Linux apps to Windows.
Hint: For people who are using GTK3 and want to cross-compile their GTK application to Windows. You maybe want to download the Mingw Windows GTK bundle, downloaded and packaged from msys2.org so you don't need to: https://gitlab.melroy.org/melroy/gtk-3-bundle-for-windows
How several OpenMP compilers create threads? I think that this may depend on concrete compiler (GCC, ICPC and Visual C++). But maybe they use some libraries like pthread..?
Most of the implementations use pthreads, since the pthreads library is on Linux and Windows. This simplifies the implementation, since they don't have to change the implementation depending on the operating system. The one implementation (of course) that differs is Microsoft. Since they only support Windows, they use the Window's threading APIs. At least on Linux, you can check for yourself what threading model is being used, by using nm on the OpenMP run time library and seeing what the external dependencies are.