[concurrency-interest] Relativity of guarantees provided byvolatile

Marko Topolnik mtopolnik at inge-mark.hr
Sat Aug 18 06:48:07 EDT 2012

Yes, we all agree on the fundamental points. I raised this question primarily to discuss the aspect of the disconnect between the public perception and the actual specification. What is generally overlooked is that a write action has no one-to-one correspondence with a single physical event, but with two events: (write done, write becomes visible). Since the JMM formal model is timeless, it doesn't have to bother with the distinction, but the name "happens-before" creates a powerful illusion that time is involved in the provided guarantees.

As I said, volatile has two disparate aspects: 

1. A guarantee of proper action ordering;

2. A best-effort promise of the action being published in a timely fashion.

Future software projects may tend to put increasing stress on this distinction, however, and demand different combinations than given by volatile. A case in point is the lazySet method of the AtomicXxx classes. The way I understand it, it gives all the guarantees of a write to a volatile, just without the promise of timeliness. Theoretically, a JVM that implemented volatile exactly as lazySet would still comply with the formal model. Whether it would completely fail at being useful is not clear-cut, though, and could depend on many subtle factors and trade-offs.

On 18. kol. 2012., at 11:27, David Holmes wrote:

> I think this is getting a little extreme and esoteric. There is a basic
> requirement that the JVM implement the Java language which means that a
> putfield (for example) must update the field (a volatile one of course) -
> which is a memory location. Similarly when the processor is requested to
> write a value to a memory location then the value must get written to
> memory. There are no time guarantees expressed about these actions but they
> must happen for the JVM and the processor to be deemed to be working
> correctly.
> The actual latencies are a quality of implementation issue.
> David
>> -----Original Message-----
>> From: concurrency-interest-bounces at cs.oswego.edu
>> [mailto:concurrency-interest-bounces at cs.oswego.edu]On Behalf Of Marko
>> Topolnik
>> Sent: Saturday, 18 August 2012 6:45 PM
>> To: Yuval Shavit
>> Cc: concurrency-interest at cs.oswego.edu
>> Subject: Re: [concurrency-interest] Relativity of guarantees provided
>> byvolatile
>> 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
>> _______________________________________________
>> Concurrency-interest mailing list
>> Concurrency-interest at cs.oswego.edu
>> http://cs.oswego.edu/mailman/listinfo/concurrency-interest

More information about the Concurrency-interest mailing list