Thread Safety, Class Loaders and the ServiceUtil class

[Garrett Rooney <ro...@electricjellyfish.net>]

So, I've been thinking about thread safety lately.  You see, I'm about
half way through Java Concurrency in Practice (go read it, it's good),
and as a result, everywhere I look I see thread safety problems.  The
first of those I'm chosing to think about is the ServiceUtil class in
Abdera ;-)

There are two static lazily loaded fields in the ServiceUtil class
that require thought.

One is the list of extension factories.  This seems like a pretty
straitforward case, we need to synchronize access to it, most likely
via the lock on ServiceUtil.class, since even though multiple
instantiations of that list are safe there are still object publishing
issues (i.e. you can see half completed objects if the compiler + JVM
reorder operations in just the wrong way) without synchronization.
Ok, so we just mark loadExtensionFactories() as synchronized and that
takes care of that one.

The other one worries me a bit more.  It's the ClassLoader field, and
it's set whenever we first need it based on the current thread's
contextClassLoader.  Now we can just throw synchronization on
getClassLoader() and setClassLoader() and call it a day, but I've
gotta wonder, is this even a good idea?  Can using the first thread's
class loader forevermore work in all cases?  Or are we assuming that
judicious use of setClassLoader() by clients of this code will make up
for any such weirdness?  I'm a bit clueless in the world of class
loaders and threads, so I've gotta ask the more experienced java
people among us, how is this sort of thing usually handled?  Is just
using the first class loader that comes along really right?  If so,
why are we allowing people to set the classloader manually?

Anyone care to enlighten me?

-garrett

Re: Thread Safety, Class Loaders and the ServiceUtil class

[James M Snell <ja...@gmail.com>]

+1 on the first point.

re: the second, the current code was written more or less with only very
basic consideration given to the various java classloader issues (which
can be quite annoying).  At some point we'll need to revisit this code.

- James

Garrett Rooney wrote:
> So, I've been thinking about thread safety lately.  You see, I'm about
> half way through Java Concurrency in Practice (go read it, it's good),
> and as a result, everywhere I look I see thread safety problems.  The
> first of those I'm chosing to think about is the ServiceUtil class in
> Abdera ;-)
> 
> There are two static lazily loaded fields in the ServiceUtil class
> that require thought.
> 
> One is the list of extension factories.  This seems like a pretty
> straitforward case, we need to synchronize access to it, most likely
> via the lock on ServiceUtil.class, since even though multiple
> instantiations of that list are safe there are still object publishing
> issues (i.e. you can see half completed objects if the compiler + JVM
> reorder operations in just the wrong way) without synchronization.
> Ok, so we just mark loadExtensionFactories() as synchronized and that
> takes care of that one.
> 
> The other one worries me a bit more.  It's the ClassLoader field, and
> it's set whenever we first need it based on the current thread's
> contextClassLoader.  Now we can just throw synchronization on
> getClassLoader() and setClassLoader() and call it a day, but I've
> gotta wonder, is this even a good idea?  Can using the first thread's
> class loader forevermore work in all cases?  Or are we assuming that
> judicious use of setClassLoader() by clients of this code will make up
> for any such weirdness?  I'm a bit clueless in the world of class
> loaders and threads, so I've gotta ask the more experienced java
> people among us, how is this sort of thing usually handled?  Is just
> using the first class loader that comes along really right?  If so,
> why are we allowing people to set the classloader manually?
> 
> Anyone care to enlighten me?
> 
> -garrett
>