How to implement a unmanaged thread-safe collection when I get this error: <mutex> is not supported when compiling with /clr

Question

I have a C++ application which consists of unmanaged C++, managed C++ and c#. In the unmanaged part I'm trying to create a thread safe collection using std::mutex.

However when I use the mutex I get the following error;

error C1189: #error : <mutex> is not supported when compiling with /clr or /clr:pure.

Any idea why I can't use the mutex? Can someone recommend a replacement for it so that I can create a thread-safe unmanaged collection?

Solution

It is not supported because the std::mutex implementation uses GetCurrentThreadId(). That's a winapi function that is not supposed to be use in managed code since it might be running on a custom CLR host that doesn't use threads to implement threading.

This is the good kind of problem to have, it shows that you are building your code wrong. Your native C++ is being compiled with /clr in effect. Which works rather too well, all C++03 compliant code can be compiled to MSIL and get just-in-time compiled at runtime, just like managed code. You don't want this to happen, your native C++ code should be compiled to machine code and get the compile-time code optimizer love.

Turn off the /clr option for this source code file, and possibly others, in your project. Right-click + Properties, General. If the mutex appears in the .h file that you have to #include in a C++/CLI source file then you have a bigger problem, use an interface or pimpl to hide implementation details.

Comments

[jww]

"Turn off the /clr option for this source code file... use #pragma managed to switch back-and-forth" - Forgive my ignorance... Can you provide a quick example of it?

[Peter]

#pragma managed(push, off) .. native code .. #pragma managed(pop) see msdn.microsoft.com/en-us/library/0adb9zxe.aspx

[void.pointer]

Does the /clr option affect native code compiled into a static library and ultimately linked into a managed library? In other words, I compiled a static library without /clr. If I compile the library that links that static library with /clr, will it affect the static library as well?

[Miral]

Yes and no. The actual object files compiled without /clr will be compiled as truly native, but any public symbols exposed by the object file (ie. pretty much anything not declared as static in the cpp) will have managed symbol thunks declared automatically for them. This is just a symbol name so mostly you don't care, but it does mean that the names of native types and methods will be visible in managed decompilation. Typically this approach of compiling as much as you can into a static non-/clr library with a thin /clr wrapper is the best way to go.

[ZivS]

Is the pimpl solution safe? are'nt you just fooling the compiler? For example C++/CLI code includes a header that holds a pimpl, and the impl uses mutex, when the C++/CLI code calls a function that in turns locks the mutex, isn't the GetCurrentThreadId being called from managed code that might not be using threads?