Version française
Home     About     Download     Resources     Contact us    
Browse thread
Using camljava library in a multithreaded context
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: -- (:)
From: EL CHAAR RABIH <RABIH.EL-CHAAR@s...>
Subject: Using camljava library in a multithreaded context
Hello,

I have been using the camljava library for a certain time, in order to
establish communications between java and caml.
The initial use of the library (maintained by Mr Leroy) supposed explicitly
that it is ocaml that initiates the call to java (it is ocaml that creates a
jvm instance).

I was confronted to the situation where java is the instancianting process
that should initialize the ocaml runtime. This was done by a little effort,
by making the following :
*	Java makes call through native methods
*	At each call, the JNIEnv variable used in the c code in jnistubs.c
is set to the actual JNIEnv passed in the native call.
*	The instanciation and deltetion of the jvm (used when ocaml was the
instanciating process) is not realised, since a valid JNIEnv is passed at
each native call.


This solution seems satisfactory, but should be used (due to use of global
variable JNIEnv) in a context where each call to a native method is atomic.
This reflects in the java world that the call to native methods should be
made synchronised.

I am now facing a context where i need to make the library coherent with a
java multi threaded context.
The JNI manual states that each java thread will have it's own JNIEnv inside
the jvm. Therefore, two threads calling the same native method will pass two
different JNIEnv values. 

The camljava API used to achieve communications between java and caml should
be made reentrant. In order to achieve this, i made a deeper change in the
camljava library by making all function calls reentrant, handling the JNIEnv
as a method parameter.
In the caml world, this was made by defining a new type, jniInterface in
jni.mli, and by making all fuctions calling java take this new type as an
additional parameter.

I am aware of the fact that the GC is not thread safe, and therefore the
synchronisation issues are delicate to handle.
The other difficulty is the fact that the caml code executed inside a native
method makes callbacks to java.

The idea that i would like to investigate more thoroughly is the possibility
to transpose the java threads into caml threads. If this is feasible, will
the execution be thread safe inside the GC ??

Another possible problem is the fact that java threads are not always
equivalent to native threads. After doing some exeperimentations, i was
executing a java multithreaded program and java threads didn't always
reflect native threads.
I am appending the trace of the executale after two consecutive runs :


****************************** first run
**********************************************

$ make -C bin runt
make: Entering directory `/cygdrive/d/recherche/java_engine1/bin'
java -Djava.class.path="./;test.jar" TestEngineT 
------------------------Thread number: 0 starts----------------------------
------------------------Thread number: 1 starts----------------------------
------------------------Thread number: 2 starts----------------------------
------------------------Thread number: 3 starts----------------------------
trying thread attach 2
trying thread attach 3
trying thread attach 4
Thread 3 speaks: calling pure caml method 1
Thread 2 speaks: calling pure caml method 1

Thread 1 speaks: calling pure caml method 1
Thread 0 speaks: calling pure caml method 1


****************
Another exception has been detected while we were handling last error.
Dumping information about last error:
ERROR REPORT FILE = (N/A)
PC                = 0x113E657D
SIGNAL            = -1073741819
FUNCTION NAME     = (N/A)
OFFSET            = 0xFFFFFFFF
LIBRARY NAME      = (N/A)
Please check ERROR REPORT FILE for further information, if there is any.
Good bye.
process detach 4
make: *** [runt] Error 1
make: Leaving directory `/cygdrive/d/recherche/java_engine1/bin'




****************************** second run
**********************************************

$ make -C bin runt
make: Entering directory `/cygdrive/d/recherche/java_engine1/bin'
java -Djava.class.path="./;test.jar" TestEngineT 
------------------------Thread number: 0 starts----------------------------
------------------------Thread number: 1 starts----------------------------
------------------------Thread number: 2 starts----------------------------
------------------------Thread number: 3 starts----------------------------
Thread 0 speaks: calling pure caml method 1
Thread 2 speaks: calling pure caml method 1

****************
Another exception has been detected while we were handling last error.
Dumping information about last error:
ERROR REPORT FILE = (N/A)
PC                = 0x77F77552
SIGNAL            = -1073741819
FUNCTION NAME     = (N/A)
OFFSET            = 0xFFFFFFFF
LIBRARY NAME      = (N/A)
Please check ERROR REPORT FILE for further information, if there is any.
Good bye.
process detach 1
make: *** [runt] Error 1
make: Leaving directory `/cygdrive/d/recherche/java_mgt_engine1/bin'

****************************************************************************
***************

Each time that a native thread calls the DLLmain function (under windows)
and goes inside the DLL_THREAD_ATTACH, i increment a global counter, and
print the message printf("trying thread attach %d",counter)
At exit (DLL_PROCESS_DETACH), i print the state of counter printf("process
detach %d",counter)

At the first run, it seems that each java thread is equivalent to a native
thread, and at exit, counter is equal to 4.
On the contrary, in the second run, all java threads seems to execute in the
same native thread.



My questions are the following :
*	Will i be able to prolonge a java thread into a caml thread
*	Will this make the execution GC safe
*	If java threads are not native threads, can there still be a work
around ?


Thanks in advance for your help and your suggestions.

Sincerely

Rabih El Chaar




*************************************************************************
Ce message et toutes les pieces jointes (ci-apres le "message") sont
confidentiels et etablis a l'intention exclusive de ses destinataires.
Toute utilisation ou diffusion non autorisee est interdite. 
Tout message electronique est susceptible d'alteration. 
SG Asset Management et ses filiales declinent toute responsabilite au titre
de ce message s'il a ete altere, deforme ou falsifie.

Découvrez l'offre et les services de SG Asset Management sur le site
www.sgam.fr 

				********

This message and any attachments (the "message") are confidential and
intended solely for the addressees.
Any unauthorised use or dissemination is prohibited. 
E-mails are susceptible to alteration.   
Neither SG Asset Management nor any of its subsidiaries or affiliates shall
be liable for the message if altered, changed or falsified. 

*************************************************************************