Sylvia,
Thanks for your feedback.
> When I look at test case 5 in
> http://www.cs.umd.edu/~pugh/java/memoryModel/CausalityTestCases.html
> I would be more sympathetic to its being forbidden if test
> case 2 was not
> allowed (I'm not suggesting that test case 2 be disalllowed).
This comparison is indeed insightful. In my next message, I send two
examples that Bill, Jeremy, and I came across recently. They are related to
tests 5 and 10. The M/P model allows one of them and prohibits the other. I
think they provide for a more apples to apples type of comparison, along the
lines of the comparison you have made of test 2 and test 5.
> So I'm inclined to agree with Sarita in that M/P is too strong. If I
> understand SC-, it at least guarantees that a value will not
> be stored into
> a memory location unless there exists some chain of events, albeit in
> different executions, that lead to the value being stored.
> Somewhere, I
> would have to have written code that very clearly created that value.
That's correct. Note that the M/P model also requires reasoning about
different executions.
>
> On my present understanding of SC-, I would be happy with it,
> with the
> caveat that I remain unconvinced, as indicated in a previous
> unanswered
> posting, that the global total order property for race free
> executions is
> essential.
I had tried to address this in a previous email. Let me elaborate some
more.
Our first goal is to provide as simple a programming model as possible. We
believe that no matter what model we come up with, most people will not want
to and should not be expected to deal with it. The only model that is
universally understood (often simply as an unconscious implicit assumption)
is SC. The problem with SC is that we do not yet know how to build SC
systems that will be able to exploit some common optimizations (particularly
in the compiler). So we do the next best thing - we have a consensus that we
want programmers to write data-race-free programs, so we say we will
guarantee SC, but only to data-race-free programs. We can get away with this
because we know how to do most (though not all) optimizations and yet
provide SC for drf programs. For other programs, we will provide only
safety/security. But we really don't want people to write programs that
exploit these safety/security guarantees either - all programmers should
write (or aim to write) data-race-free programs.
The debate we are having is about these safety/security properties. If we
opened up the can of worms to debate what base model to use for well-written
(drf) programs as well, we'd be arguing forever. There are simply too many
choices and absolutely no consensus. Furthermore, in five years, someone
else will come up with something else that is better from their point of
view. SC, on the other hand, provides a clean universally understood choice
with reasonable performance for drf programs.
I hope that helps.
Sarita
-------------------------------
JavaMemoryModel mailing list - http://www.cs.umd.edu/~pugh/java/memoryModel
This archive was generated by hypermail 2b29 : Thu Oct 13 2005 - 07:00:56 EDT