Re: Thread safe instance variables -- JAVA400-L

>Daniel,

>The types of errors you will experience are difficult
>to track down, that is why they associate this with the
>plague. I generally pass those values through as
>parameters and avoid synchronization. You
>have to synchronize the whole block from setter to
>return from any method that uses those variable and
>expects to find your set values.

>David Morris

This is great for procedural programming, but not for real O-O.  If you
must mix threads and objects, then there is no real alternative to
mastering the "synchronized" keyword and when to use it (most of the time).
After all, half the point of objects is to hold critical state.

Many (but by no means all) of the ordinary base objects are already thread
safe in that they synchronize everything in sight.  StringBuffer is one
notable example.  As will be seen in a second, String manages this another
way.

Basically, when you get to threads, there are three cases:

1.  A given object will be "guaranteed" to be accessed by only one thread.
If the guarantee slips, bugs result.  I don't use it much, but I think the
whole Swing complex meets this model.  In this model, no synchronization
needed or wanted.  This is where the nasty bugs live when the guarantee
slips up.

2.  A given object will be referenced, even if only occassionally, by more
than one thread.  If you even suspect this is going to happen, then
sychronization is required for everything except constructors.  In some
cases, even static (class) methods will need some amount of
synchronization.  A few more difficult cases will require the synchronized
keyword on a few blocks of code, but most will work fine with the keyword
applied to the method itself, which implies the lock is held for the
duration of the method.  Bugs result here mainly from forgetting to add the
keyword, especially in the "block" case.  At the method level, an eyeball
inspection pretty much puts bugs to rest beforehand.

3.  An object is "immutable."  This is not a declared, fixed property, but
one which (if coded carefully and correctly) is noted and even exploited by
the underlying JVM.  It is an object that is modified only when constructed
and thereafter never changed.  Since object construction is inherently
single threaded (at least, any sensible constructor is), the "immutable"
object can be treated as ever-after thread safe as it is "read only".  This
is because, post-construction, it is never modified and so needs no
synchronization.  String is probably the most famous such object.  If you
code:

 String a = "This " + "that";    or even

String b = a + " and another";   or even still:

a = b + a + " yet another";

. . .then variable a is "thread safe" (because it is an ordinary stack
variable) and (tricky here) the underlying String objects are thread safe
because each "+" operation constructs a new one.  If someone still points,
somehow, to the older value of "a" above, that object is still good and the
fact that variable "a" now points to a different String doesn't matter a
bit.  In fact, this closely corresponds to people's intuition, perhaps even
better seen in the following:

BigInteger c = new BigInteger("1");
  repository.recordCSomewhereInHere(c);
  c = c.add(new BigInteger("2"));  // c = c + 2

. . .where "c" is now pointing to a BigInteger with a value of 3 and yet
the original value of 1 is some other BigInteger object in whatever
"repository" does to store what's passed to it.  This is all workable
because BigInteger is also "immutable."

One potentially interesting and dangerous fact about Java is that the
synchronized keyword is not part of the signature.  So, an inherited method
could be synchronized and the parent method not and vice-versa.  Or, so it
was around 1.1.6 last time I checked that out.

Java originally wanted everyone to do 2 and 3 (especially 3).  This was no
secret at the time, though it may not be extensively written up in pubs.
If you use those rules, individually or collectively, then thread safety is
easy to manage, even if you very belatedly decide to subject your object to
a thread-rich environment.  However, practicality seems to have reared its
ugly head and 1 is now seen fairly extensively.  The place I noticed this
first coming into play was when Swing was added.



Larry W. Loen  -   Senior Linux, Java, and iSeries Performance Analyst
                          Dept HP4, Rochester MN