[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.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.