[SOSlib-discuss] Is SOSLib Thread-Safe?

[Eva S. <sc...@mi...>]

Dear Rainer,

we used JNI to bind SOSlib to the Java Code. We used the following functions:

JNIEXPORT jint JNICALL Java_sbmlSolver_SBMLSolver_initSolver (JNIEnv
*, jobject, jstring, jdouble, jint);
-> create a new ODEModel and a new IntegratorInstance.
JNIEXPORT jdoubleArray JNICALL Java_sbmlSolver_SBMLSolver_runSolver
(JNIEnv *, jobject);
-> call the method IntegratorInstance_integrateOneStep for the total time steps
JNIEXPORT void JNICALL Java_sbmlSolver_SBMLSolver_destroySolver
(JNIEnv *, jobject);
-> clean up the objects.

And we called them from the Java methods:

private native int initSolver(String sbml_filename, double totalTime,
int numSteps);
private native double[] runSolver();
private native void destroySolver();

We are using SOSlib version 1.6, libsbml version 2.3.4 and xerces-c
version 2.7.0. We compiled the library SOSlib using Microsoft Visual
C++ 2005 Express Edition.

When from the Java we call initSolver for only one object everything
works just fine. But if we call initSolver to create a second object
the results are corrupted.

example of the correcty results running one time step:
661.8319461376393 81.8319461376392 18.168053862360786

example of the corrupted results:
1.0054618704398094E-307 1.0095946694681969E-307 0.019900437649468944

I hope you have some other ideas or suggestions on how to solve the problem.

Eva.

On Fri, Sep 19, 2008 at 4:13 AM, Rainer Machne <ra...@tb...> wrote:
>
> Hi Eva,
>
> We have ourself not used Java bindings. Can you give some more details which structures/functions you are using, that might cause the problem?
> Which version are you using (there is only 1.6 and CVS :) - if CVS which date approx.)?
>
> In principle SOSlib is intended to be thread-safe! odeModel_t and integratorInstance_t (and all other) structures can be created, used and free'd independently, and should not cause any memory leaks or corruptions. From one SBML model many independent odeModel structures, and from each odeModel many independent integratorInstance structures can be created (and integrated in parallel). We are not aware of any current problems with that.
>
> Here some suggestions of past problems:
>
> I am not aware of of any memory problems in the 1.6 release either.
> However, an old CVS version used TCC-based compilation and wasn't thread-safe because unfortunately TCC (as a library) is not thread-safe - we removed TCC compilation for that reason, and currently use gcc command-line calls or - very new - our own internal compiler.
>
> Also, some recent libSBML versions had memory problems with ASTNode structure, not freeing all parts of the abstract syntax tree correctly. It could be related to this. I am currently using libSBML CVS and haven't tested their latest official release, yet. Which libSBML version are you using?
>
>
> Btw, we are currently working on a new release, which should come in the next few weeks. The code has been significantly enhanced since 1.6 and we'd be happy to support with transition to the new code. For us it would be great to get feedback already for the current CVS version before making the official release :) However, I will commit a major change today (increasing speed for large models significantly), so you might want to wait a bit.
>
> Thanks,
> Rainer
>
> On Thu, 18 Sep 2008, Eva Sciacca wrote:
>
>> Dear all,
>>
>> we built a jni interface to use SOSLib from Java. We also compiled it as a
>> dynamic library to be used from the Java objects. Now we are experiencing
>> some problems on accessing the library simultaneusly creating multiple
>> instances of Java Objects using it. It seems that, when a new object is
>> created, the memory allocated for the library gets corrupted.
>>
>> Do you know if SOSLib is Thread-Safe? Do you have had any similar problems?
>> Could you give me some advice on this problem?
>>
>> Thank you in advance.
>>
>> Eva.
>>