[concurrency-interest] Relativity of guarantees provided byvolatile

David Holmes davidcholmes at aapt.net.au
Sat Aug 18 05:27:53 EDT 2012

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

The actual latencies are a quality of implementation issue.


> -----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