RE: JavaMemoryModel: Why CnC

From: David Holmes (dholmes@dltech.com.au)
Date: Tue Jul 29 2003 - 19:20:06 EDT


Victor Luchangco wrote:
> However, your mail suggests that "the programmer must write
> correctly synchronized code" is the programmer model. Is this true?

Yes.

> That is, are we really telling programmers that incorrectly
synchronized
> code is broken,

Yes.

> and that all the other work we are doing to define
> semantics in those cases is to aid debugging?

NO! All the other work is to ensure "safety" when incorrectly
synchronized code is executed. That includes basic type-safety,
"not-out-of-thin-air" safety and related security "safety".

The problem has been to define rules that ensure all aspects of safety
we think/know we want, whilst not overly constraining the VM
implementors in terms of code optimisations/transformations.

> I had thought that while we encourage programmers to write correctly
> synchronized code, there were certain situations in which we wanted
> to allow "incorrectly" synchronized code. The classic example of
> these is relaxation-based algorithms (like many shortest-paths
> algorithms); another has something to do with initialization. I
> don't know much about these applications, but others I'm sure do.

You may be confusing "correctly synchronized" with "use of
synchronized methods/blocks". Correctly synchronized means using
volatile and final appropriately as well as locks, or the new atomic
operations in JSR-166. If an object is accessed by multiple threads
then it must be accessed either:
 - using locks (synchronized, or JSR-166 locks)
 - via a final reference
 - via a volatile reference
 - or via JSR-166 atomic operations

otherwise the program is, by definition, "broken" - though it will
still be "safe".

David Holmes

-------------------------------
JavaMemoryModel mailing list - http://www.cs.umd.edu/~pugh/java/memoryModel



This archive was generated by hypermail 2b29 : Thu Oct 13 2005 - 07:00:48 EDT