[concurrency-interest] synchronization edge case

David Holmes dcholmes at optusnet.com.au
Tue Apr 24 00:51:49 EDT 2007

Dhanji R. Prasanna writes:
> On 4/24/07, David Holmes <dcholmes at optusnet.com.au> wrote:
> > Really, as a matter of robustness, no library class should use
> a publicly accessible
> > object for its locking - except as part of an explicit protocol.
> That sounds very sensible (and is the common wisdom Ive heard).
> It looks like Classloader.loadClassInternal() also synchronizes
> on the current classloader, so is it possible to lock out an app
> (even more severely) by acquiring the monitor of the system
> classloader (and never letting go)?

In ClassLoader's case that is an explicit protocol. But yes it does mean
that a thread can lock out further classloading.

> Are these problems that have been discussed before--I am curious
> whether this is just water under the bridge or something to be
> worried about =)

Well the ClassLoader problem is mitigated if the environment runs the
foreign code eg applets/servlets etc, in their own ClassLoader. If they lock
that and stop themselves from running then that's their own silly fault. As
Class.getClassLoader() does have security checks the environment can stop
anyone from getting access to any ClassLoader other than its own. The
bootstrap loader is accessible to any code, implicitly, but can't be locked.


More information about the Concurrency-interest mailing list