RE: JavaMemoryModel: Store/load barrier

From: Shpeisman, Tatiana (tatiana.shpeisman@intel.com)
Date: Tue Oct 21 2003 - 14:31:06 EDT


Bill,
Thanks for your answer. The question relates to implementing
synchronization on IPF, which has weak memory model. According to your
answer, it would be legal (although not explicitly allowed) for the lock
B to become visible before unlock A, which is exactly what I hoped for.
The deadlock should not be a problem as long as unlock A eventually
becomes visible.

Tatiana

-----Original Message-----
From: Bill Pugh [mailto:pugh@cs.umd.edu]
Sent: Monday, October 20, 2003 9:39 PM
To: Shpeisman, Tatiana; javaMemoryModel@cs.umd.edu
Subject: Re: JavaMemoryModel: Store/load barrier

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.
>
>Thanks,
>Tatiana Shpeisman

Tatiana,
  I'm not sure I quite understand the question.

  Do you mean, in the following code:

  X = 1
  unlock A
  // position in question
  lock B
  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:

   lock B
   r1 = Y
   X = 1
   unlock A

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