Joe wrote:
> Consider this simple class with a single int property:
>
> class Foo {
> private int value;
> public int getValue() {
> return value;
> }
> public setValue(int value) {
> this.value = value;
> }
> }
>
> Should the accessors be synchronized (for transmission)? Depends on the
> context.
Yes, it does. Even in concurrent settings, sometimes (not too often)
using and even updating stale values is fine.
But this is also an interesting example of the byproducts of JMM
rules. The (unjustly well-known) atomicity gurantees for scalars are
necessary (at least for reference variables) to ensure pointer
integrity. So something safe (at least from the system's view of
safety) is guaranteed to occur even if people do not use locking when
they should. As an unfortunate but predictable consequence, people do
not always use locking in cases where their program's semantics
would demand it.
I think the similarity to main issues end there though.
Just to remind myself... the two most serious problems remain:
* Every programmer "knows" that Java provides initialization safety,
but it doesn't.
* Every compiler writer "knows" when Java allows cached/reordered reads,
including cases where it doesn't.
For whatever reason (or lack thereof), most everyone (including the
authors of the spec) believes that the programmers and compiler writers
are right about the respective issues, and the spec is wrong. But in
both cases, fixing it turns out to be harder than anyone thought, in
part because the things that people "know" are hard to nail down.
Josh wrote:
> I though a fair amount about coming up with a formal definition of
> immutability, and I believe it's decidedly non-trivial.
Yup. As Bill mentioned, you can't always see immutability in the
bytecodes. So I tentatively agree that this path isn't likely to lead
anywhere. (Aside: while immutability and latching don't play any role
in memory models, they have a long history in parallel/concurrent
processing. See especially Chandy & Misra's influential "Parallel
Program Design" text on stable predicates, the `unless' operator,
etc.)
-- Doug Lea, Computer Science Department, SUNY Oswego, Oswego, NY 13126 USA dl@cs.oswego.edu 315-341-2688 FAX:315-341-5424 http://gee.cs.oswego.edu/ ------------------------------- This is the JavaMemoryModel mailing list, managed by Majordomo 1.94.4.To send a message to the list, email JavaMemoryModel@cs.umd.edu To send a request to the list, email majordomo@cs.umd.edu and put your request in the body of the message (use the request "help" for help). For more information, visit http://www.cs.umd.edu/~pugh/java/memoryModel
This archive was generated by hypermail 2b29 : Thu Oct 13 2005 - 07:00:15 EDT