[concurrency-interest] Relativity of guarantees provided by volatile

Yuval Shavit yshavit at akiban.com
Sat Aug 18 04:24:12 EDT 2012


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++".

With no evidence to back my claim, I suspect that most uses of volatiles
are for simple isDone checks or double-checked locking. The standard
patterns for both of those don't depend on a hard, realtime guarantee of
visibility. They both depend on the write being visible very quickly for
optimal performance (in the isDone case, for responsiveness of the cancel;
and in the DCL case, so that we don't need to lock the monitor), but
neither depends on it for correctness.

If my baseless claim is right, then when we have a zillion cores per
computer in a few years, I think you might see cancellations taking a few
milliseconds longer, and DCLs will needlessly grab a few more monitors. But
not many correctness issues.

There are of course more complex uses of volatiles, such as happens-before
piggybacking for lock-free algorithms. Those are easy to get wrong even
without delays to read actions, and hopefully the people who use volatiles
for those are very advanced programmers who know that "instantaneous
guarantee" and "multithreaded correctness" don't work well together. I
don't think you'd be able to exploit this so that two threads can both
remove the same element from a correct, lockless queue -- that would create
an inconsistent ordering where one is not allowed. And if the delay in
sequential ordering means that the queue looks empty forever to a sole
consumer thread, I would say we'd be within our rights to log a bug, JLS be
damned -- just as we would be if "int i = 5" took forever.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20120818/6d61dd1b/attachment.html>


More information about the Concurrency-interest mailing list