For the record, I stand corrected on some of this. I misunderstood something
in Bill's message. He is right in that the stronger semantics allows the use
of volatiles as he describes while the weaker semantics would require more
volatiles to guarantee convergence. Thanks to Doug for clarifying.
Still, this is a use case involving a program with deliberate data races.
Our underlying philosophy throughout has been to not give any guarantees to
such programs except for the purposes of safety/security.
Sarita
> -----Original Message-----
> From: owner-javamemorymodel@cs.umd.edu
> [mailto:owner-javamemorymodel@cs.umd.edu] On Behalf Of Sarita Adve
> Sent: Saturday, April 03, 2004 2:12 AM
> To: 'javamemorymodel-cs.umd.edu'
> Subject: RE: JavaMemoryModel: Use-case for strong volatile
> interpretation
>
>
> [I have been gone for a while and slowly catching up with stuff.]
>
> I don't quite understand this reasoning. It is *possible*
> that with the
> strong semantics, this asynchronous algorithm converges a bit
> faster, but I
> believe this type of property would be hard to prove. For
> example, unless I
> am misunderstanding the algorithm, there is no guarantee in
> this scenario
> that the readers will return the value of anything other than
> the first
> writer's update. In which case, this would be identical to the weak
> semantics.
>
> In fact, as Sylvia noted, the program is not data-race-free.
> It seems to me
> the compiler could eliminate all (or all but one)
> synchronization writes. In
> which case we are again back to the weak semantics.
>
> It is my understanding that such asynchronous/chaotic
> algorithms work less
> on synchronization than on the expectation that regardless of
> synchronization, the writes will eventually be seen by all
> threads (e.g.,
> through the cache coherence protocol). Unfortunately, with
> the current JMM
> proposal, there is no guarantee that the writes will
> eventually be seen for
> programs that are not data-race-free. So such algorithms need
> to used super
> carefully, regardless of weak or strong volatile semantics.
>
> > The thing that bothers me the most about this scenario is
> > that there is
> > a synchronization idiom that works perfectly fine when you have one
> > updating
> > thread that breaks down if you have two updating threads.
>
> As indicated above, I don't agree with this. If anything,
> this further firms
> my opinion in favor of the weaker semantics - they are less
> likely to be
> misinterpreted.
>
> Please let me know if I am misunderstanding the example. But
> so far, it
> doesn't seem like a reasonable use case. (And so far, the
> majority vote for
> this issue seems to be in favor of the weaker semantics.)
>
> Sarita
>
> > -----Original Message-----
> > From: owner-javamemorymodel@cs.umd.edu
> > [mailto:owner-javamemorymodel@cs.umd.edu] On Behalf Of Bill Pugh
> > Sent: Monday, March 29, 2004 4:36 PM
> > To: javamemorymodel-cs.umd.edu
> > Subject: JavaMemoryModel: Use-case for strong volatile
> interpretation
> >
> >
> > OK, consider the following situation.
> >
> > You have some sort of simulation/relaxation based algorithm,
> > with a shared data structure, multiple threads that are updating
> > the data structure and multiple threads reading the data structure.
> >
> > The updating threads do not have to synchronize among themselves,
> > since they are updating disjoint sections of the shared data
> > structure.
> >
> > The reading threads don't need to see any particular
> iteration of the
> > update, or the most recent update. They just want to see data
> > that isn't
> > too far out of date.
> >
> > With the strong interpretation, it suffices to have a shared
> > volatile,
> > and
> > each updating thread periodically write to the volatile, and each
> > reading
> > thread periodically read the volatile.
> >
> > With the weak interpretation, this works if there is only
> one updating
> > thread. If there is more than one updating thread, the
> > updating threads
> > need to perform a CAS on the volatile rather than a write.
> >
> > The thing that bothers me the most about this scenario is
> > that there is
> > a synchronization idiom that works perfectly fine when you have one
> > updating
> > thread that breaks down if you have two updating threads.
> >
> > I talked with Doug and he agreed that this use case is at
> > least somewhat
> > compelling.
> >
> > Given this use case, and the fact that all of the official JSR-133
> > documents
> > have clearly stated the strong interpretation, I am
> planning to stick
> > with the
> > strong interpretation, even though this might cause implementation
> > issues for future DSM implementations of Java (there are
> > plenty of other
> > issues that would need to be dealt with for a DSM
> > implementation of Java
> > anyway, such as final fields).
> >
> > Bill
> >
> > -------------------------------
> > JavaMemoryModel mailing list -
> > http://www.cs.umd.edu/~pugh/java/memoryModel
> >
>
>
> -------------------------------
> JavaMemoryModel mailing list -
> http://www.cs.umd.edu/~pugh/java/memoryModel
>
-------------------------------
JavaMemoryModel mailing list - http://www.cs.umd.edu/~pugh/java/memoryModel
This archive was generated by hypermail 2b29 : Thu Oct 13 2005 - 07:01:02 EDT