3

In my Android NDK app, the C++ library runs in a different thread than the ui thread. A JNI call from C++ creates an instance of Java class Foo. I'd like to have another Java object Bar, created on the UI thread, to call methods on Foo. How do I do that?

Difficulty bonus: Foo has several native methods that call corresponding JNI functions from the C++ library. How to I ensure that those calls are thread safe?

Difficulty bonus 2: Some of Bar's methods are actually overrides of callback methods, specifically of WebViewClient. The return code of some of the methods depend on the result of the call to Foo's method. So the call to Foo would need to happen immediately.

djcouchycouch
  • 12,724
  • 13
  • 69
  • 108
  • In fact, the whole design where synchronous results are required from the thread probably stinks. Unless the JNI library is legacy or third party, consider moving Foo to the UI thread. – Seva Alekseyev Jan 28 '11 at 22:04
  • You should probably start by ignoring the fact that the methods are being called through JNI. Thread safety issues don't depend much on what programming language you're using. – fadden Jan 29 '11 at 00:53
  • Difficulty bonus 3! This is all part of a cross-platform library being developed. The client mainly uses the C++ interface, which on Android runs on a different thread than the UI. This part of the design is immutable and unaccessible to me. Hence the difficulty in implementing this. – djcouchycouch Jan 29 '11 at 06:40

4 Answers4

0

Try the Handler class. Construct a Handler in the Foo constructor. Pass the reference to the Bar class somehow. Have Bar call Handler.post().

For this to work, the thread needs to have a message queue. If it's a purely worker thread, then calling methods directly is not the answer; there's no thread interruption mechanism AFAIR. For passing stuff to worker thread, you need to simulate the message queue somewhat - have a queue of Runnnable objects (that Bar would add to) and inspect it from time to time.

Ensuring thread safety is a separate big question. SO is not big enough for everything that was said and done on this topic.

Seva Alekseyev
  • 59,826
  • 25
  • 160
  • 281
  • I was thinking of using some kind of message queue but I got tripped up on a showstopper: Some of Bar's methods are actually overrides of callback methods, specifically of WebViewClient. The return code of some of the methods depend on the result of the call to Foo's method. So the call to Foo would need to happen immediately. I'll add this detail to my main post. – djcouchycouch Jan 28 '11 at 20:10
  • So thread blocking is in order. This sucks considerably; making the UI thread wait for the worker thread to respond kills the whole purpose of threading. Not to mention is very fragile (what if the worker DOES NOT respond?). That said, Object.wait() and notify() methods are your friends (sometimes enemies). – Seva Alekseyev Jan 28 '11 at 20:17
0

So you have thread 1 and 2, thread 2 creates an object and thread 1 has an object that wants to call methods the object in thread 2.

Could you not have basically an object on thread 2 written in java with standard java thread synchronization techiques like using the synchronized keyword?

eg java Code on thread:

    // object of this type instantiated on thread 2 and called from thread 1
public class thread2Class  {
    public void doSomething(...) {
        synchronized (this) {
           // call java or jni mthod
        }
    }
 }
Chanakya
  • 178
  • 1
  • 16
0

Double message queue with notifier callback routine embedded within the message. Thread 1 posts message with callback address on Thread 2 queue. Thread 2 processes message and posts result notification on queue of Thread 1. Thread 1 calls callback routine associated with original message it posted. Thread 1 queue is UI message queue and Thread 2 is your own queue implementation of choice. Thread 2 is the manager/wrapper for the library calls. No blocking, no waiting. If Thread 1 must manage state then have it update a state model which controls which message gets posted once a response arrives.

dex black
  • 637
  • 6
  • 8
0

I would probably try to utilize something like beginInvoke() to queue the message onto the thread in the proper fashion. It has been noted here that beginInvoke() can be mocked with either Activity.runOnUiThread(), or a properly utilized AsyncTask().

Community
  • 1
  • 1
While-E
  • 1,527
  • 2
  • 20
  • 37