CLI DLL 的本机库中互斥锁的解决方法 [英] Workaround for mutex in native lib for CLI DLL

问题描述

我正在为本机 C++ 库编写 C++/CLI 包装器.在返回给 CLI 包装器的类之一中，使用线程，特别是头中的 #include 来定义类级别的互斥锁.

I am writing a C++/CLI wrapper for a native C++ library. In one of the classes that is returned back to the CLI wrapper, uses thread and, specifically #include <mutex> in the header to define the class level mutex.

问题是，一旦将标头引入 CLI 代码(启用了/clr 选项)，我就会收到错误消息，即使用/clr 或/进行编译时不支持 <mutex>clr:纯.

The problem is once the header is brought into the CLI code (with the /clr option enabled), I get the error that <mutex> is not supported when compiling with /clr or /clr:pure.

阅读这篇文章 当我收到此错误时如何实现非托管线程安全集合:<mutex>使用/clr 编译时不支持，有一篇博客文章提到了一些可能的解决方法.但是，变通方法假设您不需要任何会导致冲突的头文件，并且所有这些都可以在类函数中完成，实质上是对 CLI 应用程序隐藏了线程函数.

Reading this post How to implement a unmanaged thread-safe collection when I get this error: <mutex> is not supported when compiling with /clr, there was a blog article which mentions some possible work arounds. The workarounds, however, assume that you don't need any header files which cause a conflict and all can be done within the class functions, essentially hiding the thread functions from the CLI app.

在类级别互斥锁的情况下，情况并非如此.它必须在标题中.

In the case of a class level mutex, this is not the case. It has to be in the header.

有什么方法可以让 CLI 应用程序与线程化的本机库一起工作?

Is there any way to make a CLI app work with a native lib that is threaded?

是的，我知道托管和非托管代码之间的 GetCurrentThreadID() 问题，但正确的方法是什么?还是没有办法解决?

Yes, I am aware of the GetCurrentThreadID() issue between managed and unmanaged code, but what is the right approach? Or is there no way around it?

我对不得不合并 ZMQ 之类的东西感到畏缩，因为这是在关键部分，现在拥有三个数据副本(可能非常大)将是令人望而却步的.(一个在托管端，一个在本地，一个通过 ZMQ 中的消息缓冲区).我知道 ZMQ 的零副本，但没有尝试过托管和非托管 C++ 之间的 inproc 以查看是否可以共享内存.如果可能的话，它可能需要在整个应用程序中使用一个低级别的连续数据结构，或者遭受再次复制数据的后果.

I cringe at having to incorporate something like ZMQ because this is in a critical section and now having three copies of data (which could be very large) would be prohibitive. (one on the managed side, one on the native, and one to pass through the message buffer in ZMQ). I am aware of ZMQ's zero copy, but have not tried inproc between managed and unmanaged c++ to see if it is possible to share memory. If it is possible, it would probably require a low level contiguous data structure to be used throughout the application or suffer the consequences of copying the data again.

有没有合适的解决方案的向导?

Any wizards out there with a decent solution?

推荐答案

解决方案是使用 #ifdef 在 CLI 代码中选择性地隐藏 .h 文件中的互斥锁声明，但仍然在 cpp 本机代码中编译它.

The solution is to use #ifdef to selectively hide the declaration of the mutex in the .h file in CLI code but still compile it in the cpp native code.

nativeClass.h 文件:

nativeClass.h file:

#ifdef NATIVE_CODE
    #include <mutex>
#endif

class naticeClass {
public:
    void doSomething();
private:
#ifdef NATIVE_CODE
    mutex _mutex;
#endif

};

在 nativeClass.cpp 中:

in nativeClass.cpp:

#define NATIVE_CODE 
#include "nativeClass.h"

void nativeClass:doSomething()
{
    _mutex.lock();
    ...

}

这篇关于CLI DLL 的本机库中互斥锁的解决方法的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！