The Artima Developer Community
Sponsored Link

Weblogs Forum
Java Threads

36 replies on 3 pages. Most recent reply: Oct 18, 2005 3:19 PM by Bruce Eckel

Welcome Guest
  Sign In

Go back to the topic listing  Back to Topic List Click to reply to this topic  Reply to this Topic Click to search messages in this forum  Search Forum Click for a threaded view of the topic  Threaded View   
Previous Topic   Next Topic
Flat View: This topic has 36 replies on 3 pages [ « | 1 2 3 ]
Tim Peierls

Posts: 3
Nickname: tpeierls
Registered: Sep, 2005

Re: To Tim Peierls Posted: Sep 14, 2005 3:33 PM
Reply to this message Reply
Advertisement
Bruce: Tried emailing you, no spam blocker, no response. You can try me at tpeierls@gmail.com. My response was to ask if tomorrow was too late for me to take a look.

Wu Yongwei

Posts: 1
Nickname: adah
Registered: Sep, 2005

DCLP is restored Posted: Sep 15, 2005 10:39 PM
Reply to this message Reply
Hi Bruce,

I think you should read `The "Double-Checked Locking is Broken" Declaration':

http://www.cs.umd.edu/~pugh/java/memoryModel/DoubleCheckedLocking.html

I believe with volatile and its new semantics, DCLP is now OK to use in Java. And you can have a good understanding of the related issues reading this article.

Best regards,

Yongwei

Chris Morris

Posts: 1
Nickname: chrishmorr
Registered: Sep, 2005

Volatile pre 1.5 Posted: Sep 19, 2005 6:31 AM
Reply to this message Reply
Before Java 1.5, the situation with "volatile" can be summarized simply: any program that is correct with volatile variables would also be correct without the volatile keyword, although its performance might be worse.

Frank Zitters

Posts: 5
Nickname: fzitters
Registered: Aug, 2005

Re: Volatile pre 1.5 Posted: Sep 19, 2005 2:12 PM
Reply to this message Reply
I don't think this is true, at least according to the specs. Even though volatile's semantics were strengthened in 1.5, it already affected visibility and ordering in earlier versions.

Peter Booth

Posts: 62
Nickname: alohashirt
Registered: Aug, 2004

Re: Java Threads Posted: Sep 20, 2005 11:37 PM
Reply to this message Reply
The Wong and Oaks book is sufficiently flawed for me to have disposed of my copy. I found it to be a confusing, ambiguous and at times misleading - these are critical errors when the topic is concurrent programming. Concurrent programming is complex, has subtle edge cases, and is often described in an overlsimplistic fashion.

Volatile in Java 1.4 is simply broken and of no value. In Java 1.5 it is no longer the case that increment operations on primitives must be synchronized to guarantee correctness in a multitheaded context. The atomic variables in java.util.concurrent.atomic are a new language feature that allow thread safe operations (that derive from a conditional compare and Set instruction) without incurring the cost of synchronization.

The Lewis and Berg book is very different from Wong & Oaks, and extremely useful at a nuts and bolts level. I think the software world is still crying out for the ultimate Java threading book that combines correctness, clarity of exposition, deep coverage, and breadth.

Matthew Zipay

Posts: 2
Nickname: mattz
Registered: Oct, 2005

Re: Java Threads Posted: Oct 18, 2005 1:45 PM
Reply to this message Reply
From the Java Language Specification, 2nd Ed (section 8.3.1.4 volatile Fields):

"A field may be declared volatile, in which case a thread must reconcile its working copy of the field with the master copy every time it accesses the variable. Moreover, operations on the master copies of one or more volatile variables on behalf of a thread are performed by the main memory in exactly the order that the thread requested. ... [Access to members declared volatile] occur exactly as many times, and in exactly the same order, as they appear to occur during execution of the program text by each thread."

The example used in the spec explicitly uses post-decrement operators on volatile fields, so I assume that this behavior is correct (and that the authors' explanation is incorrect). My simplistic understanding of "volatile" is that it reduces concurrency problems that may surface as a result of context switching, albeit with a performance hit (for having to sync up with the master copy on *every* access).

Bruce Eckel

Posts: 875
Nickname: beckel
Registered: Jun, 2003

Re: Java Threads Posted: Oct 18, 2005 3:19 PM
Reply to this message Reply
You should not make the mistake of confusing volatility and atomicity in general.

Making a variable volatile does not change non-atomic operations to atomic operations except for the "simple" assignments and reads for long and double.

The increment and decrement operations are never atomic, regardless of whether the field they are operating on is volatile or not.

In the midst of an increment, it is possible to have a context switch, thus leaving the field in an unstable condition. You need to mutex the field in order to prevent another thread from seeing that field in an incorrect state.

Flat View: This topic has 36 replies on 3 pages [ « | 1  2  3 ]
Topic: Back to Generics: Contravariance and Erasure Previous Topic   Next Topic Topic: Designing a Language for Library Developers


Sponsored Links



Google
  Web Artima.com   

Copyright © 1996-2017 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use - Advertise with Us