|
However, on hardware that is weakly consistent (i.e. allows unordered storage access), this is not true. Meaning basically all hardware eventually. Its just a matter of time as its an obvious future direction for hardware performance. And please... if you are thinking about showing the group a variation on the double checked locking algorithm... don't. They don't work. Richard D. Dettinger iSeries Java Data Access Team Democracy's enemies have always underestimated the courage of the American people. It was true at Concord Bridge. It was true at Pearl Harbor. And it was true today. Rochester Post-Bulletin Tuesday September 11, 2001 |---------+----------------------------> | | Fred | | | Kulack/Rochester/| | | IBM@IBMUS | | | Sent by: | | | java400-l-admin@m| | | idrange.com | | | | | | | | | 09/19/2002 11:58 | | | AM | | | Please respond to| | | java400-l | | | | |---------+----------------------------> >----------------------------------------------------------------------------------------------------------------------------| | | | To: java400-l@midrange.com | | cc: | | Subject: RE: FW: Java Vs RPG on iSeries | | | | | >----------------------------------------------------------------------------------------------------------------------------| 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. "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 _______________________________________________ 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.
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.