[drlvm] potential for race condition in jni.cpp jni_init()

[Geir Magnusson Jr <ge...@pobox.com>]

Trying to solve some of the compilation warnings, I was going through 
jni.cpp.

Do we care that apr_initialize() isn't really protected from multiple 
invocations by concurrent threads?  My read of apr_initialize() is that 
it's not protected either.  I assume someone throught this through?

geir

Re: [drlvm] potential for race condition in jni.cpp jni_init()

[Alexei Fedotov <al...@gmail.com>]

Hello, Geir,

It seems to me that you identified the problem correctly. My
assumption about planned design was as follows, but this design wasn't
reflected in Eugenes' implementation.

To process any invocation API call one should call to a component
manager which knows about multiple VMs etc.  Component manager
interfaces are synchonized.

A component manager is statically linked with APR. It is a singleton.
It inititalizes porting library in a constructor. The call to
constructor is protected with compare and swap guard.

Thanks.


On 11/6/06, Geir Magnusson Jr <ge...@pobox.com> wrote:
> Trying to solve some of the compilation warnings, I was going through
> jni.cpp.
>
> Do we care that apr_initialize() isn't really protected from multiple
> invocations by concurrent threads?  My read of apr_initialize() is that
> it's not protected either.  I assume someone throught this through?
>
> geir
>
>


-- 
With best regards,
Alexei,
ESSD, Intel