Bill said:
> > Every class that contains any final field is initialization safe
> > (i.e., first-publication-safe).
> > Others need not be.
> >
> >As mentioned before, there aren't any interesting cases where this
> >doesn't have the right effect in practice. When any fields are
> >mutable, programmers will need to lock anyway to eliminate conflicts.
>
> Continuing in Doug's spirit...
>
> Shouldn't this be that any final field is initalization safe, but
> that other fields in the same class may not be?
I think this is acceptable too. It occurred to me though that the other
fields must also be initialization safe "for free", so it might as
well be stated more broadly. At least in any implementation I can
imagine. But sometimes I don't have a good enough imagination.
One conceptually reasonable interpretation of the narrow version is
that the final qualifier has memory effects that support its other
semantics in the same sense that synchronized and volatile do. And
that if people do not declare intended semantics via
final/synchronized/volatile, then they get programs with few semantic
guarantees.
(In retrospect it was a bad idea to pursue definition of `immutable'
when behavior should really be based on something already defined -
final.)
How much do you alpha folks hate this? It definitely limits range of
applicability of zero-fill trick, and still cries out for good
barrier optimization techniques to be developed.
Josh said:
> Of course all of these suggestions horrify me. The Java philosophy has
> always been that it's the compiler's job to do the optimizing. Programmers
> should not have to think about this stuff. It would lead to all sorts of
> bugs.
But can you show me any case where it would break a coding idiom that
you think is otherwise prudent? The only construct I know is the "bad"
version of double-check, which I don't think is in widespread use, is
hopefully not used at all by non-experts, and is very fragile to begin
with. I do agree that breaking it leads to holes in the
locks-are-solely-for-exclusion story, but so do the rules surrounding
scalars (<=32 bits). I think both of the holes in the story are
livable, in that novices will not usually need to understand them
deeply so long as they get everything else right..
-- 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:17 EDT