At 5:05 PM -0500 6/30/99, Sarita Adve wrote:
>****************************************************************************
>(1) Model is too weak: needs control dependence orderings
>****************************************************************************
>The alternative model does not impose any orderings for control dependences.
>Consider the following example:
>
> Initially A = B = 0
> Processor 1 Processor 2
> if (A == 1) if (B == 1)
> B = 1 A = 1
>
> Result: Both processors return 1 for their reads
The reason I left off control dependences is due to the complications
caused by exceptions. In Java, almost every instruction is control
dependent on every previous instruction not throwing an exception.
Now, you can often do compiler analysis that will tell you that a
particular instruction cannot possibly raise an exception.
Furthermore, you have to consider other ways of eliminating control
dependence. For example, if we could do forward substitution into the
conditional tests, then we could decide the value of the tests and
eliminate the branch and control dependence.
Coming up with a definition for this that works for compiler amalysis
and transformations as well as processor memory models will be an
interesting research challenge. (In other words, I don't know how to
do it :-) ).
For the case above, a thread is only allowed to write a value to
share memory if it is absolutely guaranteed that the write will
occur. So it is hard to see how this reordering could arise in
practice.
At 5:05 PM -0500 6/30/99, Sarita Adve wrote:
>****************************************************************************
>(2) Model is too weak: needs ordering from a read to an unlock (condition 3
>only orders writes and unlocks)
>****************************************************************************
Sounds reasonable. More intuitive reason:
If you do a read while you hold a lock, you would often expect to
have private access to that field. If you delay the read until after
the unlock, some other thread may come in and smash the value you
expected to read.
****************************************************************************
(3) Model is too strong: condition 2 should not order "memory op --> lock"
****************************************************************************
This was more modeled on the existing MM. I'll have to think about
it; it sounds reasonable.
****************************************************************************
(4) Model is too strong: condition 3 should not order "unlock --> write"
****************************************************************************
We might be able to get rid of this. We can do something special for
constructors, so it doesn't have to be done in terms of the standard
lock and unlock.
To do a construct, modify, publish idiom, we might require:
Point tmp;
synchronized (...) { tmp = new Point(); tmp.x = 17; tmp.y = 42; }
synchronized (...) { p = tmp; }
This would require the write to p to come after the writes that
initialize and update the object, even with the relaxed constraints.
Bill
-------------------------------
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:16 EDT