[concurrency-interest] Relativity of guarantees provided by volatile

Yuval Shavit yshavit at akiban.com
Sat Aug 18 05:10:57 EDT 2012

So, I agree with you that people's wording assumes some sort of timely
visibility. And you're right that the reader isn't *guaranteed* to ever
observe the write, in the same way that I'm right that ++i on a local var
isn't *guaranteed* to take fewer than 7 years. I think a JVM which
exploited either non-guarantee would be up for a critical-importance
performance bug.

I also agree that the expectation of blink-of-an-eye coherency is one that
could well be challenged in the future. Taking my example of a
distributed-node JVM, if one node is in Austrialia and the other is in NYC,
and the volatile read is in a lockless whose HB edge also pulls in all the
data in some huge element in the queue (an in-memory cache of a DB table,
say) -- then I could imagine the reader chugging along for a few seconds
pretending not to see the write, until finally it and all its implications
are sync'ed across the network, at which point it finally sees the write
and everything implied by it (ie, the huge element). That may well surprise
some programmers and generate bug reports like "why is my write to a
one-byte boolean taking 15 seconds to be seen?" -- and when those questions
crop up on SO, people on this list are going to reap some major karma
points. ;-)

In summary:
   1) I agree that there's no guarantee for the write to ever be seen
   2) I agree that in the future, it may take some noticeable time for the
write to be seen
   3) I contend that if point 1 were exploited to the point of the write
not being seen in a reasonable timeframe (where "reasonable" depends on the
platform, includes some wiggle room, etc), that this would be a performance
(not correctness) bug against the JVM

Good night!

On Sat, Aug 18, 2012 at 4:44 AM, Marko Topolnik <mtopolnik at inge-mark.hr>wrote:

> On 18. kol. 2012., at 10:24, Yuval Shavit wrote:
> > On Sat, Aug 18, 2012 at 3:35 AM, Marko Topolnik <mtopolnik at inge-mark.hr>
> wrote:
> > However, what is troubling is the belief of practically every developer
> out there that there's a hard realtime GUARANTEE of the instantaneous
> visibility of volatile writes.
> >
> > Do they? I certainly believe that the read is going to see the write
> very quickly, but a hard, realtime guarantee? Between the JIT, GC and other
> apps that may hog CPU, I don't even depend on a realtime guarantee between
> "int i = 5" and "i++".
> Yes, my wording was too strong. I didn't mean "hard realtime", but a hard
> guarantee, as opposed to a soft promise of best effort. The volatile
> modifier gives you two things: a hard guarantee of proper observed ordering
> of actions, and a *hint* towards the timely publishing of a write. This is
> where confusion enters---take this typical argument: "Without the volatile
> modifier the reading thread is not guaranteed to ever observe a write to
> the var". Well guess what, with the modifier it still isn't *guaranteed* to
> ever observe it. This fact is very counterintuitive and many people would
> even religiously oppose it. I cannot escape the troubling feeling this
> gives me---a developer should have the right intuition about his code and
> shouldn't shake his head in disbelief when shown any piece of code and the
> output that code may legally produce. Somewhere down the line this must
> matter.
> -Marko
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20120818/caf5cdf0/attachment-0001.html>

More information about the Concurrency-interest mailing list