Hi folks,
Yesterday I contacted Doug Lea privately with a few questions,
and Doug has requested that I join the list so that my questions
can be distributed to a wider forum. So here goes. My questions
to Doug can be seen below.
____________________________________________________
Doug,
Thanks for the clarification. I have already found the page
http://www.cs.umd.edu/~pugh/java/memoryModel, in fact that is where I found
the link to the document I quoted. I presume that by "new version" you are
referring specifically to
http://www.cs.umd.edu/~pugh/java/memoryModel/newest.pdf.
I am still a bit unclear on the requirements regarding "same" lock,
and didn't manage to find the section where it was referenced.
Suppose I code (in a writer):
synchronized (a)
{
synchronized (b)
{
p.x++;
}
}
For a reader to be confident of seeing the correctly synchronized
value of p.x, must they write:
synchronized (a)
{
synchronized (b)
{
// do something with p.x
}
}
or can they write:
synchronized (a)
{
// do something with p.x
}
or:
synchronized (b)
{
// do something with p.x
}
Basically, I suppose what I am having difficulty with is: assuming
that 'synchronized' implies a read-barrier at start and a write-barrier
at end, the "same" lock requirement would seem to suggest that only
a partial barrier is required, i.e. only those fields written while
the writer's lock is held need to be flushed at lock release time
(otherwise "any" lock would do for the reader). In that case, surely
the read-barrier at lock acquire for a reader would be required to go
to main memory at least for all fields accessed within the reader's
synchronized block (not necessarily for other fields).
Or, reworded:
(1) If 'synchronized' read & write barriers are required to be "total",
then it is not clear why "same" lock requirements would hold, since
a reader synchronizing on any lock (after the writer has exited its
synchronized block) would get the updated values from main memory.
(2) If 'synchronized' read & write barriers are permitted to be "partial",
then it appears necessary to define the semantics so that the read and
write barriers are with respect only to the actual fields possibly
written by the writer and possibly read by the reader (which, in the
general case, is probably uncomputable for the minimal set, but in
particular cases could be computable as a subset of all cached values).
If we are to permit "partial" barriers, and we define the "write set"
of a writer to be the set of fields possibly written, and the "read set"
of a reader to be the set of fields possibly read, then if the
writer's write-set and the reader's read set both contain "p.x", then
it is still unclear why a "same" lock requirement would be necessary.
Anyway, I think the question boils down to "when readers and writers
potentially synchronize on multiple locks, which locks are the ones
owning the responsibility for the necessary read & write barriers?"
The "same" lock requirement appears to be ambiguous in this case.
> -----Original Message-----
> From: Doug Lea [mailto:dl@cs.oswego.edu]
> Sent: Tuesday, 2 September 2003 12:18 p.m.
> To: eireland@sybase.com
> Subject: Re: Synchronization and the Java Memory Model
>
>
> >
> > A writing thread releases a synchronization lock and a reading thread
> > subsequently acquires that same synchronization lock."
> >
> > Specifically, what is the rationale for stating that the reading thread
> > must acquire the same synchronization lock (as opposed to some
> other lock)?
> > Since at a later point, you state:
> >
> > "In essence, releasing a lock forces a flush of all writes
> from working
> > memory employed by the thread, and acquiring a lock forces a
> (re)load of
> > the values of accessible fields. While lock actions provide exclusion
> > only for the operations performed within a synchronized
> method or block,
> > these memory effects are defined to cover all fields used by
> the thread
> > performing the action."
>
> You are right that these can be (but should not be) interpreted as
> contradictory (sorry). This was written while the memory model was in
> the process of being revised. The new version makes clear that only
> those values protected by the same lock are scoped with respect to
> visibility. See http://www.cs.umd.edu/~pugh/java/memoryModel/
>
> > Are you aware of current JVM implementations or desirable future
> > implementations or optimizations where the "same" lock requirement
> > is beneficial as opposed to an "any" lock requirement?
>
> Yes, the easiest examples are experimental JVMs using distributed
> shared memory. But multiprocessors are increasing becoming similar
> to clusters, and these rules are sure to be exploited.
>
> Sorry for the confusion; I hope this helps!
>
> -Doug
>
____________________________________________________
Evan Ireland eireland@sybase.com +64 4 934-5856
Sybase EAServer Engineering, Wellington, New Zealand.
_____________________________________________________
-------------------------------
JavaMemoryModel mailing list - http://www.cs.umd.edu/~pugh/java/memoryModel
This archive was generated by hypermail 2b29 : Thu Oct 13 2005 - 07:00:51 EDT