RE: FW: Java Vs RPG on iSeries

[Fred Kulack <kulack@xxxxxxxxxx>]

Hmmm.... I'm not exactly sure if you're missing the point.

The point is that you simply must synchronize any shared object/data.

You cannot safely access an object or variables
initialized/created/modified
in one thread from another without a synchronized block somewhere (in both
those threads) to protect access and ensure that your thread accesses the
correct data.

So, assume thread 1 does this:
String      x = new String("Testing");

Now, thread 2 does this:
if (x.equals("Testing")) {
      // true
}
else {
      // false
}

Because you've shared data between threads without synchronization, its
possible that x is not initialized, but in addition, the finer point that
we're talking about:

String.equals() MAY return FALSE even though x may have been updated
correctly.

I.e. its legal (if you don't do synchronization) for any/all of x, x.value
and x.count to have not
been flushed to storage yet, or to have their store order re-arranged such
that
when you access them in thread 2, they have their old or new values.


>From jdk14, java.lang.String() here's an excerpt:

public final class String implements
    implements java.io.Serializable, Comparable, CharSequence
{
    private char value[];
    private int count;

    public String(String original) {
      this.count = original.count;
      if (original.value.length > this.count) {
          // The array representing the String is bigger than the new
          // String itself.  Perhaps this constructor is being called
          // in order to trim the baggage, so make a copy of the array.
          this.value = new char[this.count];
          System.arraycopy(original.value, original.offset,
                       this.value, 0, this.count);
      } else {
          // The array representing the String is the same
          // size as the String, so no point in making a copy.
          this.value = original.value;
      }
    }

   public boolean equals(Object anObject) {
      if (this == anObject) {
         return true;
      }
      if (anObject instanceof String) {
         String anotherString = (String)anObject;
         int n = count;
         if (n == anotherString.count) {
            char v1[] = value;
            char v2[] = anotherString.value;
            int i = offset;
            int j = anotherString.offset;
            while (n-- != 0) {
               if (v1[i++] != v2[j++])
                  return false;
            }
            return true;
         }
      }
      return false;
   }
}

"The stuff we call "software" is not like anything that human society
  is used to thinking about. Software is something like a machine, and
  something like mathematics, and something like language, and
  something like thought, and art, and information...
  but software is not in fact any of those other things."
Bruce Sterling - The Hacker Crackdown

Fred A. Kulack - IBM eServer iSeries - Enterprise Application Solutions
ERP, Java DB2 access, Jdbc, JTA, etc...
IBM in Rochester, MN  (Phone: 507.253.5982   T/L 553-5982)
mailto:kulack@us.ibm.com   Personal: mailto:kulack@magnaspeed.net
AIM Home:FKulack  AIM Work:FKulackWrk
MSN Work: fakulack@hotmail.com



                      "David Morris"
                      <David.Morris@plu        To:       
<java400-l@midrange.com>
                      mcreek.com>              cc:
                      Sent by:                 Subject:  RE: FW: Java Vs RPG on 
iSeries
                      java400-l-admin@m
                      idrange.com


                      09/19/2002 04:17
                      PM
                      Please respond to
                      java400-l





I am trying to understand your alarming declaration and trying to see
how it would be a problem with a String. I can see how out of order
execution could create a duplicate object in a case where you are
doing something like this:

if (null==myString) String myString = new String("string");

and it would seem that any lock that doesn't key on a single item (not

tied to a thread) will potential fail. But I think it would be a pretty

unusual case for this to be a problem with a String or other immutable

object like a Double as long as you use the class comparitor and
comparable interfaces. Is this the case or am I missing the point?

David Morris

>>> kulack@us.ibm.com 09/19/02 10:58AM >>>

On 09/19/2002 at 01:28:33 AM, java400-l-admin@midrange.com wrote:
What happens if you _define_ an object such that its contents _never
change_ after the "new" (constructor) finishes?  Answer:  It is
automatically thread safe and everyone and his brother can have
references
to it without any synchronization.  That's an immutable object.  Very
relevantly, "String" is an immutable object and so is always thread
safe.
--- end of excerpt ---

Careful... Which JVM release? Pre or Post JSR 133?
Multithreading is a bit too complex even for this statement. Its
almost
always
more complex than someone thinks it is. JSR 133 tries to address it in
some
pieces, but
I don't know details about when that JSR was/is going to be complete
implemented, but
this is NOT true in general.  Do you know?

For others on the list...
On most hardware the statement about immutable objects is true.
However, on hardware that is weakly  consistent (i.e. allows unordered
storage access), this is
not true.

To really be safe, you simply CANNOT access objects/storage in one
thread
that were
created/initialized/modified in any other thread WITHOUT
synchronization.
PERIOD.
There are many tricks and exceptions that DON'T WORK. In a
multi-threaded
application,
anything that can theoretically fail, WILL, and you can't rely on it.

Here's one reference, see this.
http://servlet.java.sun.com/javaone/resources/content/sf2002/conf/sessions/pdfs/1073.pdf


In the "Idioms and Pitfalls" sections, see "Safe Immutable Objects".
You'll need to be a member of JDC (Java Developer Connection) but see
this:
The one I liked most was a similar presentation in the 2000 JavaOne.
_______________________________________________
This is the Java Programming on and around the iSeries / AS400 (JAVA400-L)
mailing list
To post a message email: JAVA400-L@midrange.com
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/cgi-bin/listinfo/java400-l
or email: JAVA400-L-request@midrange.com
Before posting, please take a moment to review the archives
at http://archive.midrange.com/java400-l.