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