Mixing C++11 std::thread and C system threads (ie pthreads)

Question

I am writing a multithreaded C++ program and wish to use a multithreaded C library.
This library expects me to use the native system methods to create it some worker threads and pass control to its run() function using code such as this:

void system_specific_thread_init();
#ifdef _WIN32
    DWORD WINAPI system_specific_thread_run( LPVOID unused )
    {
        library_run();
        return 0;
    }

    void system_specific_thread_init()
    {
        Createthread(NULL, 0, system_specific_thread_run, NULL, 0, NULL);
    }
#else
    void* system_specific_thread_run(void *unused)
    {
        library_run();
        return NULL;
    }

    void system_specific_thread_init()
    {
        pthread_t id;
        pthread_create(&id, NULL, system_specific_thread_run, NULL);
    }
#endif
system_specific_thread_init();

after which it will use the relevant native system mutex methods to other native system threads to call its functions while getting on with is own work.

However, I am using the C++11 <thread> library to create and manage all my threads. I wish to create the worker thread(s) with std::thread(library_run) and call the library functions from other such threads.

Is it safe to do this, or will the DS9K cause demons to fly out of my nose?

Answer 1

C++11 threads may or may not have a member function named native_handle() ; it's implementation-defined whether this exists. If it exists, it returns an object of type native_handle_type ; it's implementation-defined what an object of this type can be used for. So read your documentation.

Answer 2

The C++ standard doesn't specify how C++ threads interact with any other thread library, but in general I would expect a C++ implementation to use the underlying system thread library, so your usage should be safe.

Being able to use a third-party library that uses the system thread library locking primitives is such a common use case that it should be expected to work (otherwise C++ threading support would be almost useless in lots of real-world situations). As Pete points out, anything involving thread handles/ids can be more tricky (but shouldn't be required from reading your question).

Answer 3

It depends on what the library is actually doing. Using pthreads for mutices and such shouldn't be a problem. However in case the library actually tries to manage the threads using functions like pthread_join , it will likely lead to problems. It might still work on systems where pthread is the standard (unix and such), since std::thread can be implemented as a very thin wrapper around pthreads , but that would obviously be very implementation dependent and not something I would count on working even for future versions of the same compiler. Similar Arguments can be made for usage of CreateThread .

Answer 4

The new C and C++ standards (C11 and C++11) both implement the same model of threads and their interfaces should be compatible. So whatever platform provides you with an implementation of C++11 threads should also be able to provide you the same in C. If it doesn't it is certainly only temporary.

If you are on a platform that has pthread as a native thread model (probably a POSIX platform) then the C++11 thread are almost certainly build on top of it. But beware, the calling conventions between these two thread models are only similar, not equal. Eg the return value of thread functions is void* for pthread and int for C++11/C11.

But if you are in a hurry, and can't wait that your compiler vendor also provides the C11 interface, you could just implement shallow interfaces around the C++ functions by your own. This mustn't be a big deal to do so.

Answer 5

Is it safe to do this, or will the DS9K cause demons to fly out of my nose?

I wouldn't try it for mission critical software. After trying WinApi call FreeLibraryAndExitThread on std::thread, it exited the thread but did not released the dll. (It worked with CreateThread)