I'm calling a C function that resides in a dll from a java thread. This C function runs indefinitely and processes video frames in real time, outputting a result for each frame.
I want to spawn another java thread to read the results from the processing function without interrupting the function. I also need to implement some kind of thread control to protect from reading corrupted data.
Any ideas?
The global is controlled by your C environment.
I suspect that you should do this:
Create a function that returns the value of the global variable and call it from java using JNI.
Implement your synchronization stuff in C.
You can embed your C function in a executable that will be started by your java thread. The C function can post results into a pipe or send them through a socket to your java thread. This gives you the flexibility to even have your C function running on one machine and the java thread on another.
Related
I have a java process, which call a c++ .so lib, java code like this:
com.bj58.spider.faiss.Index index; //create by swig, real c++ obj
index.search(query.length, q.cast(), k, distances.cast(), labels.cast()); //call c++ lib,\
func search will use multi threads(openmp) run results.
index.search is a c++ interface, Underlying call use openmp to multiple thread running for loop.
the result is OK, but I found as soon as execute index.search, the number of threads which in the java process will grow. And it never released. how to solve the problem?
I recently wrote some code[1][2] that tried using JNA to make calls to sched_setaffinity in an attempt to set the affinity of the process to a particular core. The first argument of the function sched_setaffinity is the process id.
Calling the function with pid as 0(referring to the process itself) works fine. However, I'd like to be able to set the affinity on a thread id basis rather than the process. Is there any way I could do that?
https://github.com/eQu1NoX/JavaThreadAffinity/blob/master/src/com/threads/ctest.c
https://github.com/eQu1NoX/JavaThreadAffinity/blob/master/src/com/threads/ThreadAffinity.java
There is a function called pthread_setaffinity_np that can set the CPU affinity mask of the thread thread to the CPU set pointed to by cpuset.
cpu_set_t cpuset;
CPU_ZERO(&cpuset);
CPU_SET(core_id, &cpuset);
pthread_t current_thread = pthread_self();
pthread_setaffinity_np(current_thread, sizeof(cpu_set_t), &cpuset);
This piece of code can set the a thread to the core(represented by core_id).
As far as I know, a Java Thread is not always matched to a thread in OS. So I'm not quite sure whether this piece of native code can help you.
I was use C++ signals
sigaction
struct sigaction sigact;
and set all attributes to use signals
now I want to use it in Java what's the equivalent in java
to the include "signal.h"
I have two threads:
one run from the beginning of the program
and the other run at the signal Alarm
I was implement the functionality in C++ using Signals as shown and now I want to implement it using java
Edited to put my Goal:
actually my Goal to run the second Thread When the signal arrives from the first thread
Thus sounds like a typical "XY-Problem".
In plain Java you have no access to OS-signal. They are platform specific and Java strifes to be platform agnostic. Also: calling Java from a signal handler with JNI might be "fun" (as explained in Dwarf Fortress).
So you have to go back to the drawing board and think about what is the problem you want to solve and stop thinking about how to solve it with signals.
That said: if you insist on signals and are not afraid to use internal stuff which might change on a whim: Take a look at sun.misc.Signal.
EDIT Now the question made it clear, that the signalling takes place within one JVM. For this signals are definitely the wrong thing in Java.
So the simplest solution is to create and start the second thread directly from within the first thread. No signalling required.
The next best solution is to code a "rendezvous point" using Object.wait() in the second thread (using any object instance but the Thread itself) and Object.notify() or notifyAll() from the first thread. Searching for these terms in a Java tutorial will bring up enough examples.
I'm writing a Java program that uses a hardware driver written in c. This hardware driver starts a callback thread, and you can register callback functions to be called when stuff happens. How can I attach this thread to the jvm so that it can call the Java methods for these callbacks? I only have the thread id returned from the start_callbacks() function, returned as an int, but it is the pthread_t used in the call to pthread_create().
One way I found is to use pthread_once on the start of every callback function and attach the thread there. But then there is no way to detach it. I tried to use pthread_cleanup_push/pop, but they need to be called as a pair so that didn't work.
It seems to me that my only option to do this right is to attach and detach the thread at every callback call. Or rewrite the driver somewhat, which I really don't want to do.
Is there something I missed?
That's exactly what the JNI calls AttachCurrentThread() and DetachCurrentThread() are for.
The solution to you problem can be resolved with thread_local storage (C++ 11 and higher). This allows you to attach to an arbitrary thread, and then it will automatically detach when the thread exist (even when you didn't create the thread and have no control over it's life cycle).
A sample example of how to implement that in C++ can be found in my answer here:
https://stackoverflow.com/a/59934966/8367574
I have a JNI C++ code being called from a multi-threaded java application
This C++ code has 2 global static variables a boolean and a string.
For some reason i keep getting segmentation fault from this code . Any idea what could lead to this ? I know this is not thread safe, but i am treating the variables as read only from the java application and only the C++ code is able to modify the values of these variables
Help much appreciated
EDIT : This code runs on a Linux machine . And runs for months at a time without any issues, then it issues a signal 11 segmentation fault and the JVM crashes.
If you're calling the C++ code from multiple threads, and the C++ code has global static variables, then it would be amazing if it worked. The simplest thing to try is to put a lock around the call, i.e. in the Java side change
native int callToCppFunction(int parameter);
to
synchronized native int callToCppFunction(int parameter);
to ensure that only one thread can be in the C++ code at a time.
Then there's another possible issue, which I bumped on about a year ago: apparently in Windows dlls it may not be enough to serialize calls to it (i.e. use synchronized). They may also require to be called from the same thread each time. This answer offers an explanation to how that can be. The solution is to make a single threaded executor to the Java side, and route all calls to the native code through it.