After reading the proposal I have a question. Why does the
memory model have to specify some sort of reasonable behavior
for incorrectly synchronized programs? Why can't surprising
things happen when there isn't synchronization or some form of
memory barrier?
It looks like the examples so far require some very interesting
code and a very bright JVM. Rather than disallow having a
bright JVM, shouldn't the memory model make it clear that bad
and unexpected things can happen when there is no
synchronization or memory barriers?
--Paul
--- Bill Pugh <pugh@cs.umd.edu> wrote:
> SUMMARY:
> For some time, I've said that the new Java memory model
> should
> enforce something vaguely described as "out-of-thin-air"
> safety for
> incorrectly synchronized programs.
>
> "Out-of-thin-air" safety requires that every read of a
> variable v see
> the value written by some write to v. Now, because there is
> no simple
> global clock, we can't require that a read see the value
> written by a
> _previous_ write. However, we also want to avoid causal
> loops, in
> which an event causes/justifies itself.
[snip rest of discussion]
__________________________________________________
Do You Yahoo!?
Yahoo! Autos - Get free new car price quotes
http://autos.yahoo.com
-------------------------------
JavaMemoryModel mailing list - http://www.cs.umd.edu/~pugh/java/memoryModel
This archive was generated by hypermail 2b29 : Thu Oct 13 2005 - 07:00:40 EDT