问题简介
我通过 JNI 在一个进程中使用 C++ 和 Java.对于有问题的用例，C++ 线程和 Java 线程都在访问相同的数据，它们在 C++ 端这样做，我想正确同步访问.
I am using C++ and Java in one process via JNI. For the use case in question, both a C++ thread and a Java thread are accessing the same data, they are doing so on the C++ side, and I want to properly synchronize the access.
到目前为止，我几乎所有的 JNI 线程同步都在 Java 端，答案很明显:使用提供的 Java 并发包和内置的并发语言特性.不幸的是，答案在 C++ 方面并不那么明显.
So far, almost all of my JNI thread synchronization has been on the Java side where the answer is obvious: use the provided Java concurrency package and the built-in concurrency language features. Unfortunately, the answer is not so obvious on the C++ side.
到目前为止我的尝试简介
我尝试使用 pthreads 互斥锁，认为即使我不使用 pthreads 创建线程它也可以工作，但在尝试锁定时偶尔会卡住 - 我将在下面展示一个示例.
I tried using a pthreads mutex thinking that it might work even though I'm not using pthreads to create threads, but that occasionally gets stuck when trying to lock - I'll show an example of that farther below.
在我当前的特定用法中，c++ 会在 1 秒计时器上轮询 Java 提供的更改(这不是我想要的，但鉴于遗留的 C++ 代码).Java 线程通过调用原生函数提供数据，c++ 将数据复制到 c++ 结构中.
In my current, specific usage, c++ is polling for changes provided by Java on a 1 second timer (not what I'd like, but I'm not sure how I would make it event-driven given the nature of the legacy c++ code). The Java thread provides data by calling a native function and c++ copies the data into a c++ structure.
这是代码中的情况类型(发生在 2 个线程上，Thread1 和 Thread2):
This is the type of situation in code (happens on 2 threads, Thread1 and Thread2):
代码示例
注意一个 SSCCE，因为它缺少 TheData 和 TheDataWrapper 的定义，但它们包含什么并不重要.假设它们仅包含几个公共 int，如果这有助于您的思考过程(尽管在我的情况下，它实际上是多个 int 数组和 float 数组).
Note quite an SSCCE, as it's missing definitions for TheData and TheDataWrapper, but it doesn't really matter what they contain. Assume they merely contain a couple of public ints if that helps your thought process (though, in my case, it's actually multiple arrays of int and arrays of float).
C++:
class objectA
{
void poll();
void supplyData(JNIEnv* jni, jobject jthis, jobject data);
TheDataWrapper cpp_data;
bool isUpdated;
void doStuff(TheDataWrapper* data);
};
// poll() happens on a c++ thread we will call Thread1
void objectA :: poll()
{
// Here, both isUpdated and cpp_data need synchronization
if(isUpdated)
{
do_stuff(&cpp_data);
isUpdated = false;
}
}
// supplyData happens on the Thread2, called as a native function from a java thread
void objectA :: supplyData(JNIEnv* jni, jobject jthis, jobject data)
{
// some operation happens that copies the java data into a c++ equivalent
// in my specific case this happens to be copying ints/floats from java arrays to c++ arrays
// this needs to be synchronized
cpp_data.copyFrom(data);
isUpdated = true;
}
Java:
class ObjectB
{
// f() happens on a Java thread which we will call Thread2
public void f()
{
// for the general case it doesn't really matter what the data is
TheData data = TheData.prepareData();
supplyData(data);
}
public native void supplyData(TheData data);
}
到目前为止我已经尝试过的详细信息
当我如下尝试 pthread 的锁定时，有时执行会卡在 pthread_mutex_lock 中.在这种情况下不应该出现死锁，但为了进一步测试，我运行了一个场景，其中 supplyData 根本没有被调用(没有提供数据)，所以应该不会出现死锁，然而，对 poll 的第一次调用偶尔会挂起.也许在这种情况下使用 pthreads 互斥锁不是一个好主意?或者也许我做了一些愚蠢的事情并一直忽略它.
What I've Tried so far Details
When I tried pthread's locking as below, sometimes execution gets stuck in pthread_mutex_lock. There should not be a deadlock in this situation, but just to test further I ran a scenario where supplyData was not getting called at all (no data was being supplied), so no deadlock should have been possible, yet the first call to poll will occasionally hang anyway. Perhaps using a pthreads mutex is not a good idea in this situation? Or perhaps I did something stupid and keep overlooking it.
到目前为止，我尝试使用以下 pthreads:
So far, I tried using pthreads as below:
代码示例
C++:
class objectA
{
pthread_mutex_t dataMutex;
... // everything else mentioned before
}
// called on c++ thread
void objectA :: poll()
{
pthread_mutex_lock(&dataMutex);
... // all the poll stuff from before
pthread_mutex_unlock(&dataMutex);
}
// called on java thread
void objectA :: supplyData(JNIEnv* jni, jobject jthis, jobject data)
{
pthread_mutex_lock(&dataMutex);
... // all the supplyData stuff from before
pthread_mutex_unlock(&dataMutex);
}
另一个我想过但没有做的选择
我还考虑过使用 JNI 回调到 java 以使用 java 的并发控制请求锁定.这应该可以工作，因为任何一个线程都应该根据需要在 java 端阻塞.但是，由于从 c++ 访问 java 过于冗长，我希望避免遇到这种头痛.我可能可以制作一个将 JNI 调用封装到 java 中以请求 java 锁的 c++ 类；这将简化 c++ 代码，尽管我想知道仅针对线程锁在 JNI 上来回交叉的开销.
I also considered using JNI to call back into java to request a lock using java's concurrency control. That should work, as either thread should block on the java side as needed. However, since accessing java from c++ is overly verbose, I was hoping to avoid going through that headache. I probably could make a c++ class which encapsulates JNI calls into java to request a java lock; that would simplify c++ code, though I wonder about the overhead of crossing back and forth over JNI just for thread locks.
根据@Radiodef 的评论，这似乎没有必要.JNI 似乎包含 MonitorEnter/MonitorExit 函数，这些函数已经处理了 c++ 端的锁定.在 Java 端与传统锁同时使用这些锁时存在缺陷，因此 请在使用前阅读这里.我将尝试这个，我希望 MonitorEnter/MonitorExit 将是答案，我建议@Radiodef 从评论中做出答案.
It seems this is not necessary, per the comment by @Radiodef. It appears JNI includes MonitorEnter/MonitorExit functions which already handle the locking on the c++ side. There are pitfalls when using these at the same time as conventional locks on the java side, so please read here before using. I will be trying this out, and I expect that MonitorEnter/MonitorExit will be the answer and I recommend @Radiodef make an answer out of the comment.
我怎样才能正确同步呢?pthread_mutex_(un)lock 应该工作吗?如果没有，我可以使用什么来在 C++ 线程和 Java 线程之间进行同步?
How could I properly synchronize this? Should pthread_mutex_(un)lock work? If not, what can I use to synchronize between the C++ thread and the Java thread?
这里没有提供特定于 JNI 的 C++ 代码，因为 JNI 桥正在工作并且我可以来回传递数据.问题特别是关于正确通信的 c++/java 线程之间的正确同步.
No JNI-specific C++ code is provided here since the JNI bridge is working and I can pass data back and forth. The question is specifically about proper synchronization between c++/java threads that are otherwise correctly communicating.
如前所述，我宁愿避免使用轮询方案，但这可能会成为另一个问题.遗留的 c++ 代码在 X/motif 中显示其用户界面的一部分，如果我没记错的话，上面的 c++ 线程恰好是用于显示的事件线程.一旦插入此类的 java 用户界面，java 线程最终将成为 java 事件调度线程，尽管目前 java 线程是一个自动测试线程；无论哪种方式，它都是一个单独的 java 线程.
As mentioned before, I would prefer to avoid the polling scheme, but that might end up being another question. The legacy c++ code displays its part of the user interface in X/motif, and if I recall correctly the c++ thread above happens to be the event thread for display. The java thread will end up being the java event dispatch thread once the java user interface for this class is plugged in, though for now the java thread is an automated test thread; either way, it's a separate java thread.
C++ 线程附加到 JVM.其实那个是创建JVM的C++线程，所以应该是默认附加的.
The C++ thread is attached to the JVM. In fact, that is the C++ thread that created the JVM, so it should be attached by default.
我已经成功地将其他 Java 用户界面元素插入到该程序中，但这是 C++ 第一次需要来自 Java 的需要同步的非原子数据.有没有公认的正确方法来做到这一点?
I have been successful with plugging in other Java user interface elements into this program, but this is the first time C++ has needed non-atomic data from Java which needed to be synchronized. Is there a generally accepted correct way to do this?
推荐答案
如果两个线程都连接到JVM，那么可以通过JNIEnv的MonitorEnter(jobject) 和 MonitorExit(jobject) 函数.就像听起来一样，MonitorEnter 获取对提供的 jobject 的锁定，而 MonitorExit 释放对提供的 jobject.
If both threads are attached to the JVM, then you can access the JNI's synchronization via JNIEnv's MonitorEnter(jobject) and MonitorExit(jobject) functions. Just as it sounds, MonitorEnter aquires a lock on the provided jobject, and MonitorExit releases the lock on the provided jobject.
注意:有一些陷阱需要注意！注意 MonitorEnter 描述的倒数第二段和 MonitorExit 描述的最后一段关于混合和匹配 MonitorEnter/MonitorExit 与您可能认为兼容的其他类似机制.
NOTE: There are some pitfalls to be aware of! Notice the second to last paragraph of MonitorEnter's description and the last paragraph of MonitorExit's description about mixing and matching MonitorEnter/MonitorExit with other similar mechanisms which you might otherwise think are compatible.
参见 这里
MonitorEnter
jint MonitorEnter(JNIEnv *env, jobject obj);
jint MonitorEnter(JNIEnv *env, jobject obj);
输入与引用的底层 Java 对象关联的监视器通过 obj.输入与引用的对象关联的监视器由 obj.obj 引用不能为 NULL.每个 Java 对象都有一个与其关联的监视器.如果当前线程已经拥有与 obj 关联的监视器，它增加监视器中的计数器指示此线程进入监视器的次数.如果与 obj 关联的监视器不属于任何线程，当前线程成为监视器的所有者，设置条目此监视器的计数为 1.如果另一个线程已经拥有该监视器与 obj 关联，当前线程一直等待，直到监视器释放，然后再次尝试获得所有权.
Enters the monitor associated with the underlying Java object referred to by obj. Enters the monitor associated with the object referred to by obj. The obj reference must not be NULL. Each Java object has a monitor associated with it. If the current thread already owns the monitor associated with obj, it increments a counter in the monitor indicating the number of times this thread has entered the monitor. If the monitor associated with obj is not owned by any thread, the current thread becomes the owner of the monitor, setting the entry count of this monitor to 1. If another thread already owns the monitor associated with obj, the current thread waits until the monitor is released, then tries again to gain ownership.
通过 MonitorEnter JNI 函数调用输入的监视器不能使用 monitorexit Java 虚拟机指令或同步方法返回.MonitorEnter JNI 函数调用和monitorenter Java 虚拟机指令可能会竞相进入与同一对象关联的监视器.
A monitor entered through a MonitorEnter JNI function call cannot be exited using the monitorexit Java virtual machine instruction or a synchronized method return. A MonitorEnter JNI function call and a monitorenter Java virtual machine instruction may race to enter the monitor associated with the same object.
为避免死锁，通过 MonitorEnter JNI 输入监视器函数调用必须使用 MonitorExit JNI 调用退出，除非DetachCurrentThread 调用用于隐式释放 JNI监视器.
To avoid deadlocks, a monitor entered through a MonitorEnter JNI function call must be exited using the MonitorExit JNI call, unless the DetachCurrentThread call is used to implicitly release JNI monitors.
链接:
JNIEnv 接口函数表中的索引 217.
Index 217 in the JNIEnv interface function table.
参数:
env:JNI 接口指针.
env: the JNI interface pointer.
obj:一个普通的Java对象或类对象.
obj: a normal Java object or class object.
返回:
成功返回0"；失败时返回负值.
Returns "0" on success; returns a negative value on failure.
和
监视器退出
jint MonitorExit(JNIEnv *env, jobject obj);
jint MonitorExit(JNIEnv *env, jobject obj);
当前线程必须是与之关联的监视器的所有者obj 引用的底层 Java 对象.线程递减指示它已进入此的次数的计数器监视器.如果计数器的值变为零，则当前线程释放监视器.
The current thread must be the owner of the monitor associated with the underlying Java object referred to by obj. The thread decrements the counter indicating the number of times it has entered this monitor. If the value of the counter becomes zero, the current thread releases the monitor.
本机代码不得使用 MonitorExit 退出通过同步方法或监视器进入 Java 虚拟机说明.
Native code must not use MonitorExit to exit a monitor entered through a synchronized method or a monitorenter Java virtual machine instruction.
链接:
JNIEnv 接口函数表中的索引 218.
Index 218 in the JNIEnv interface function table.
参数:
env:JNI 接口指针.
env: the JNI interface pointer.
obj:一个普通的Java对象或类对象.
obj: a normal Java object or class object.
返回:
成功返回0"；失败时返回负值.
Returns "0" on success; returns a negative value on failure.
例外:
IllegalMonitorStateException: 如果当前线程不拥有监视器.
IllegalMonitorStateException: if the current thread does not own the monitor.
因此，尝试使用 pthreads 的问题中的 C++ 代码应更改如下(代码假定 JNIEnv* 指针是以典型的 JNI 方式事先以某种方式获取的):
So the C++ code in the question which attempted to use pthreads should be changed as following (code assumes the JNIEnv* pointer was acquired somehow beforehand in typical JNI fashion):
class objectA
{
jobject dataMutex;
... // everything else mentioned before
}
// called on c++ thread
void objectA :: poll()
{
// You will need to aquire jniEnv pointer somehow just as usual for JNI
jniEnv->MonitorEnter(dataMutex);
... // all the poll stuff from before
jniEnv->MonitorExit(dataMutex);
}
// called on java thread
void objectA :: supplyData(JNIEnv* jni, jobject jthis, jobject data)
{
// You will need to aquire jniEnv pointer somehow just as usual for JNI
jniEnv->MonitorEnter(dataMutex);
... // all the supplyData stuff from before
jniEnv->MonitorExit(dataMutex);
}
向提供答案的@Radiodef 致敬.不幸的是，这是作为评论.我一直等到第二天下午，以便有时间让 Radiodef 给出答案，所以现在我正在这样做.感谢 Radiodef 提供解决此问题所需的推动.
Kudos to @Radiodef who provided the answer. Unfortunately it was as a comment. I waited until afternoon next day to allow time for Radiodef to make it an answer, so now I'm doing it. Thank you Radiodef for providing the nudge I needed to fix this.
相关推荐
最新文章