[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: r17214, JavaHL thread local storeage and reentrant calls

From: Andrew Vaughan <ajv-lists_at_netspace.net.au>
Date: 2005-11-14 21:08:41 CET

On Tue, 15 Nov 2005 05:00, Garrett Rooney wrote:

> JavaHL uses thread local storeage to keep track of a variety of
> things, for example it stores Java level exceptions there, so it's
> possible to say "an exception was thrown" in some C code, and then
> later it gets reported to the JVM. This is all stored in this
> JNIThreadData object, which is created when we enter a JavaHL function
> and destroyed when we leave it. Now the problem comes from when we
> call a JavaHL function from another JavaHL function, there's only one
> JNIThreadData object per thread, so they stomp all over each other.
> The solution was to make the JNIThreadData object really a linked
> list, so when we start the second call into a JavaHL function we just
> push another JNIThreadData onto the stack, use it for this call, then
> pop it off at the end leaving the old one there for the existing call
> to pick up and use.
> Now the problem becomes one of the mappings between the C level APR
> calls JavaHL makes to manipulate the thread local storeage and the
> Java level threads that are actually making the calls into JavaHL. If
> a C level thread and a Java level thread map to the same "thing"
> underneath, we can reasonably expect the C level thread local storeage
> to work correctly, but if the JVM is doing something fancy, mapping
> multiple Java level threads to a single OS level thread (a N-M
> threading scheme, green threads, whatever you want to call it), then
> it seems like this house of cards is likely to come crashing down.
(I haven't studied the code, just skimmed the log, and read your explanation
above). There should be no problems with either green or native threads,
_iff_ the Java code is properly synchronized. (eg. either using
SVNClientSynchronized.java or synchronizing on some other Object themselves.)

Note that deadlock is still possible.

> So is this something we need to care about? I really don't know
> enough about Java/JNI to say one way or the other, but it seems weird
> enough to be concerned about.
Caring about possible threading issues is definitely worth doing.
There are green thread Java implementations available (eg Kaffe).

Thanks for caring.
Andrew V.

To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Nov 14 21:11:29 2005

This is an archived mail posted to the Subversion Dev mailing list.