This post deals with the problem of using stateful C code from *multiple Java threads*. With JNI ([Java Native Interface](https://en.wikipedia.org/wiki/Java_Native_Interface)) it is possible to glue C code to a Java environment. There are [many helpful tutorials](https://www3.ntu.edu.sg/home/ehchua/programming/java/JavaNativeInterface.html) on how to call C code and receive results. JNI helps to reuse existing, often highly complex and computationally expensive, C code.
The introductory tutorials often stop once it is made clear how to repackage (simple) datatypes and do not mention threads. It is, however, reasonable to expect JNI code to take into account thread-safety and proper multi-threading. In all but the simplest cases it is not that straightforward to share state at the C side and allow JNI code to be called from multiple Java threads. Incorrectly sharing state can lead to memory leaks and segmentation faults (segfaults) and crashes the application. In what follows, a way to share thread-local state is presented.
It is quite common to have an `init`, `work` and `dispose` method to create a state, use that state and do some work and finally dispose of used resources. Each Java thread independently calls these methods and expects results. These results should not change if multiple Java threads are calling the same methods. In other words: the state should remain Java thread-local. A typical Java class could look like the code below.
With the Java code in mind, the C code should know which Java thread is used and which state needs to be used for the work. Luckily there is a way to find out: [The JNI specification states that each `JNIEnv` is local to a Java thread](https://developer.ibm.com/languages/java/articles/j-jni/). So we can use the `JNIEnv` pointer to identify a thread. This is the idea that is used below.
The code maps a `JNIEnv` pointer to a structure with (any) state information. An unordered map is used for this mapping. There is, however, still a problem: multiple threads can call the init method at once. So multiple threads potentially write to the `unordered_map` at the same time which leads to problems. To prevent this from happening a mutex is used. The mutex, together with a [unique lock](https://www.cplusplus.com/reference/mutex/unique_lock/), makes sure that only a single thread writes to the unordered map. The same holds for the dispose method.
The work method does not need a unique lock since it does not write to the unordered map and reading from multiple threads is no problem.
````c
#include
#include
const int DATA_ARRAY_SIZE = 300000 * 2;
struct BridgeState {
jfloat *data;
};
//A hash map with a JNIEnv * as key and a BridgeState * as value
std::unordered_map stateMap;
//A mutex to ensure that writes to the stateMap are synchronized.
std::mutex stateMutex;
JNIEXPORT jint JNICALL Java_init(JNIEnv *env, jobject object) {
//Makes sure only one thread writes to the stateMap
std::unique_lock lck(stateMutex);
BridgeState *state = new BridgeState();
uintptr_t env_addresss = reinterpret_cast(env);
state->data = new jfloat[DATA_ARRAY_SIZE];
uintptr_t state_addresss = reinterpret_cast(state);
stateMap[env_addresss] = state_addresss;
return 1;
}
JNIEXPORT jint JNICALL Java_work(JNIEnv *env, jobject object) {
//get a ref to the state pointer
uintptr_t env_addresss = reinterpret_cast(env);
BridgeState *state = reinterpret_cast(stateMap[env_addresss]);
//do something with state->data, e.g. calculate the sum
int sum = 0;
for (int i = 0; i < DATA_ARRAY_SIZE; i++) {
state->data[i] = state->data[i] + 1;
sum += (int)state->data[i];
}
return sum;
}
JNIEXPORT jint JNICALL Java_dispose(JNIEnv *env, jobject object) {
//Makes sure only one thread writes to the stateMap
std::unique_lock lck(stateMutex);
uintptr_t env_addresss = reinterpret_cast(env);
BridgeState *state = reinterpret_cast(stateMap[env_addresss]);
stateMap.erase(env_addresss);
//cleanup memory
delete[] state->data;
delete state;
return 0;
}
````
This conceptual code has been lifted from a JNI library doing actual work: The [JGaborator JNI bridge](https://github.com/JorenSix/JGaborator/blob/master/gaborator/jgaborator.cc) . If you need more information on how to compile and use this construct in actual code, please have a look at the [JGaborator GitHub repository](https://github.com/JorenSix/JGaborator)