Function complete signal between c++/Java with threading involved

Question

Within a C++ JNI function (semi-pseudo included below), there is at least one (and potentially two) additional thread(s) created at the client_ = new VClient(&callback_) line. I figured that the completion of this function would be enough, but apparently when the next function (another JNICALL function) is "immediately" called after this, it causes a SEGFUALT ("immediately" is in quotes because the function is called as quickly as someone can push the next button). I figure it is because creating the new VClient did not yet complete by the time the Init function returns and the next function is called, since the client_ is being used in the next function.

I am rather new to all this threading business, and I am not sure whether this is a correct line of thinking. I am used to code executing sequentially, thus when the code moves on from the client_ line, it is because everything with that line has been completed. Is it possible for the code to move on from this line, and return from the JNI Init function before the new VClient has been fully created? If so, how would I have this function wait until the class/object has finished being created?

JNIEXPORT void JNICALL Java_com_ClassDir_Init(JNIEnv *env, jobject obj)
{
  LOGI("%s", __PRETTY_FUNCTION__);
  if(!client_)
  {
    LOGI("Initializing client");
    client_ = new VClient(&callback_);
    [Bunch of JNI/JAVA class and methodID lookup and saving]
  }
  else
    LOGI("Client already initialized");
}

*The callback_ is a class that handles sending enum type signals to JNI/JAVA to update on program progress.

Answer 1

You said that VClient constructor creates threads. Creating threads is a synchronous process: the execution of VClient ctor does not continue until the thread is fully created and also most probably started, as i don't see any other method call on VClient istance to do it. What is not synchronous, is this start of the thread. It does not mean "fully operational", just that your main thread has instructed the created thread to start running in its own context. When the new thread's execution loop is set up and entered is completely asynchronous (to your VClient construction) and up to the thread scheduling. So if your "next JNI function" tries to call into that thread and use some resources there, the resource must be already avaliable (which means that you expect the new thread already have progressed to the point of making it available) and the access to that resource must be guarded for threadsafe access.

So you need to become less new in this threading business :-) Look up two essential building blocks:

1. wait condition (also named "blocking condition variable"). After calling VClient ctor, you will wait on an object which you need to pass into the thread. The thread will notify the condition when it finishes its essential work, hence unblocking the wait in your first thread.
2. mutex. Whenever there is a resource (data structure) which can be concurrently accessed by execution of multiple threads, you need to lock the mutex before the accessing code and unlock afterwards. The later arriving thread will block on the lock until the first thread finishes. Otherwise when two threads try to modify the same memory, you will get strange results or a straightforward crash.

These are implemented differently in various APIs per OS and per the framework. Even different frameworks on the same OS tend to be different. But the philosophy is equal.

Btw, i take for granted that client_ is declared in a way that it does not go out of scope when "the next JNI function" tries to use it. Which probably means a global variable in JNI implementation - i don't see any class wrapper for the native code.