[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: Alexander Kitaev <alex_at_tmate.org>
Date: 2005-11-14 22:04:43 CET

Hello Mark,

> I do not believe that SVNClientSynchronized is synchronizing
> on a specific instance of the class. If it were, then it
> wouldn't be thread safe at all. It is synchrnonizing on a
> static instance of the .class which I believe will apply to
> all instances of the class and therefore all threads.
If you're talking about non-static synchronized java methods, then
non-static methods uses object monitor for synchronization, not class one:

(from Java langauge spec.
http://java.sun.com/docs/books/jls/third_edition/html/classes.html#8.4.3.6):
A synchronized method acquires a monitor (§17.1) before it executes. For a
class (static) method, the monitor associated with the Class object for the
method's class is used. For an instance method, the monitor associated with
this (the object for which the method was invoked) is used.
...

Actullay making non-static method synchronized is the same as writing:

public void test() {
  synchronized(this) {....}
}

To make sure that all calls to SVNClient object are synchronized you should
use a single instance of SVNClient per application or per project, so that
it will be possible to run several parallel task that work with unrelated
working copies.

Alexander Kitaev,
TMate Software,
http://tmate.org/
http://jetbrains.com/tmate/

> -----Original Message-----
> From: Mark Phippard [mailto:markp@softlanding.com]
> Sent: Monday, November 14, 2005 21:41
> To: Garrett Rooney
> Cc: ajv-lists@netspace.net.au; dev@subversion.tigris.org;
> Patrick Mayweg; rooneg@gmail.com
> Subject: Re: r17214, JavaHL thread local storeage and reentrant calls
>
> rooneg@gmail.com wrote on 11/14/2005 03:23:54 PM:
>
> > On 11/14/05, Andrew Vaughan <ajv-lists@netspace.net.au> wrote:
> >
> > > (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.)
> >
> > But what if they were using different SVNClientSynchronized objects
> > entirely? It seems like there are any number of different ways you
> > could have two separate threads calling into JavaHL without any
> > locking at all between them, which would mean you're vulnerable to
> > this sort of problem.
>
> I do not believe that SVNClientSynchronized is synchronizing
> on a specific instance of the class. If it were, then it
> wouldn't be thread safe at all. It is synchrnonizing on a
> static instance of the .class which I believe will apply to
> all instances of the class and therefore all threads.
>
> We use SVNClientSynchronized in Subclipse.
>
> Mark
>
>
>
>
> ______________________________________________________________
> _______________
> Scanned for SoftLanding Systems, Inc. and SoftLanding Europe
> Plc by IBM Email Security Management Services powered by MessageLabs.
> ______________________________________________________________
> _______________
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Nov 14 22:07:17 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.