> [...]I'm sure there is something involved in the JNI work that causes
> your
> problem. In particular, do you ensure that the JNI work is completely
> finished before the constructor continues executing? Is there anything
Is there anything I need to do to ensure it? Doesn't Java have to wait
until JNI calls return (my DLL is singe-threaded, and the JNI functions
return results which are used in the constructor)?
> in the JNI code that is shared between objects?
That's a good point. If I think about it the problem might arise from the
fact that finalize() can be invoked at any time on any thread. I think I
can rely on constructors being called one after another in a loop. And as
I learnt I can also rely on finalize() being called after the constructor
of the same object. However I can't rely on finalize() being called while
no constructor for another object is running. And as my DLL uses a
C++ container to track all resources this container might be used from two
threads at the very same time - one adding a resource, another one
removing another resource.
Thanks for your comments, Patricia! They were very helpful! I'll look go
back to code and check the details.
Boris
Patricia Shanahan - 21 Apr 2007 16:40 GMT
>> [...]I'm sure there is something involved in the JNI work that causes
>> your
[quoted text clipped - 4 lines]
> until JNI calls return (my DLL is singe-threaded, and the JNI functions
> return results which are used in the constructor)?
I was thinking about the possibility of multi-threading in the DLL.
>> in the JNI code that is shared between objects?
>
[quoted text clipped - 7 lines]
> be used from two threads at the very same time - one adding a resource,
> another one removing another resource.
That container seems like a good candidate.
Assuming a single garbage collection thread, delaying unreachability of
any of the objects until after the last construction would limit the
container to being accessed from one thread at a time, preventing the
problem.
Patricia