JNI and multi-threading?

[Devnull]

I'm considering writing an application using JNI and the NDK. Under
the NDK, I would like to use OpenGL to draw graphics. Additionally, I
would like to make use of the NDK to convert data from the Camera
Preview (from Java, of course) into a suitable format for OpenGL to
draw (which, remember, is also in the JNI library).

I assume that the Camera preview is asynchronous and so I must ask:
Will this be a problem? Will I be running into any race conditions or
other thread synchronization issues? If so, what are some things I
could do?

Thanks for your help.

[fadden]

On Oct 25, 11:16 pm, Devnull <rekd...@gmail.com> wrote:
> I assume that the Camera preview is asynchronous and so I must ask:
> Will this be a problem? Will I be running into any race conditions or
> other thread synchronization issues? If so, what are some things I
> could do?

The race conditions and synchronization issues in native code are
about equivalent to the ones you'll encounter when working with Java
code. The solutions are also about equivalent; for example, you can
synchronize on objects with JNI's MonitorEnter / MonitorExit.

Were there specific situations about which you have questions or
concerns?

[Devnull]

Thank you for the quick response, fadden.

Building more on my previous message, I imagine something like the
following:
- GLSurfaceView that calls my native library for Render/input events
(like the san-angeles example).
- Camera preview object that also calls into the same native library.

Now, the GLSurfaceView is rendering on its' own thread at some
interval. Additionally, the Camera preview is being received on a
separate thread at some different interval. At some point, the Camera
preview data has to safely make the jump from the Camera preview
thread to the GLSurfaceView thread (or at least into a safe area for
the GLSurfaceView to access) so that it can safely be turned into an
OpenGL texture and rendered.

My question is about the last part. What is the "Android way" of
making that happen? Would you suggest using MonitorEnter/MonitorExit,
or perhaps pthread mutexes when this needs to happen? One idea that
comes to mind is having the native Camera Preview code first do the
conversion to a buffer, and then use a mutex to lock OpenGL while it
loads it as a texture, unlocking it when it is finished. Does this
seem like a good idea? Can you see any problems that might come with
this approach?

Thanks again for your help.

[Clapfoot]

This approach is similar to the approach I have been using for my
OpenGL
game. I basically have one Java thread for my game logic and another
for
my OpenGL code. At the end of every "game loop" iteration I lock the
OpenGL thread and swap in a list of render objects. This has worked
quite
well for me so far but I'm not sure if its the definitive way of doing
things
on Android. I'm eager to hear other's comments/responses on this
issue.

[fadden]

On Oct 26, 1:11 pm, Devnull <rekd...@gmail.com> wrote:
> My question is about the last part. What is the "Android way" of
> making that happen? Would you suggest using MonitorEnter/MonitorExit,
> or perhaps pthread mutexes when this needs to happen? One idea that
> comes to mind is having the native Camera Preview code first do the
> conversion to a buffer, and then use a mutex to lock OpenGL while it
> loads it as a texture, unlocking it when it is finished. Does this
> seem like a good idea? Can you see any problems that might come with
> this approach?

I'm not acquainted with the camera or OpenGL code, so I can't make
specific recommendations.

It does seem like you'd want to have some notion of buffer ownership,
i.e. the buffer full of goodies can be owned by the camera or OpenGL,
but not both. Given sufficient memory, you may want to double-buffer
it so they spend less time waiting for each other. MonitorEnter has a
bit more overhead than using pthread mutexes directly, but you're
probably not doing this 1000x per second, and MonitorEnter is
equivalent to the Java "synchronized" keyword which may make it easier
for native and Java code to interact.