[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
This archive was generated by hypermail 2b29 : Thu Oct 13 2005 - 07:01:02 EDT