At 2:16 PM -0700 10/20/03, Shpeisman, Tatiana wrote:
>Please excuse me if my quesion is naive. Does new Java memory model
>require a store/load barrier between dynamically successive unlock
>and lock operations on different locks? According to JSR-133
>Cookbook it does but I cannot figure out how this follows from the
>happens-before relationship defined in the memory model.
I'm not sure I quite understand the question.
Do you mean, in the following code:
X = 1
// position in question
r1 = Y
do you need a store/load barrier at the position in question?
Not really, although typically the barriers would more typically be
associated with the unlock and lock. All that really matters is that
any thread that subsequently acquires a lock on A is ordered with
respect to the write to X, and any write of Y that occurs before a
previous unlock off B is visible to the read of Y
Say, for the moment, you were in a very hypothetical situation
where you knew that it was never the case that anyone ever tried
acquire a lock on B while already holding a lock on A.
In that (contrived) example, you could transform the above code to:
r1 = Y
X = 1
The conditions above are to ensure that this transformation can't
introduce deadlock. It still wouldn't be a good idea, and not
something that the model explicitly allows, but it wouldn't generate
any behavior not allowed by the model.
JavaMemoryModel mailing list - http://www.cs.umd.edu/~pugh/java/memoryModel
This archive was generated by hypermail 2b29 : Thu Oct 13 2005 - 07:00:52 EDT