<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content="text/html; charset=ISO-8859-1" http-equiv=Content-Type>
<META name=GENERATOR content="MSHTML 8.00.6001.19298"></HEAD>
<BODY bgColor=#ffffff text=#000000>
<DIV><SPAN class=296550023-17082012><FONT color=#0000ff size=2 
face=Arial>Nathan,</FONT></SPAN></DIV>
<DIV><SPAN class=296550023-17082012><FONT color=#0000ff size=2 
face=Arial></FONT></SPAN> </DIV>
<DIV><SPAN class=296550023-17082012><FONT color=#0000ff size=2 face=Arial>Is 
there a synchronization order here that indicates that the read occurs after the 
write? "subsequent" is not defined by wall-clock time as externally 
observed.</FONT></SPAN></DIV>
<DIV><SPAN class=296550023-17082012><FONT color=#0000ff size=2 
face=Arial></FONT></SPAN> </DIV>
<DIV><SPAN class=296550023-17082012><FONT color=#0000ff size=2 face=Arial>And to 
batch responses :) Hotspot's implementation requires that all writes will become 
visible without need for explicit barriers/fences to force 
that.</FONT></SPAN></DIV>
<DIV><SPAN class=296550023-17082012><FONT color=#0000ff size=2 
face=Arial></FONT></SPAN> </DIV>
<DIV><SPAN class=296550023-17082012><FONT color=#0000ff size=2 
face=Arial>David</FONT></SPAN></DIV>
<BLOCKQUOTE 
style="BORDER-LEFT: #0000ff 2px solid; PADDING-LEFT: 5px; MARGIN-LEFT: 5px">
  <DIV dir=ltr class=OutlookMessageHeader align=left><FONT size=2 
  face=Tahoma>-----Original Message-----<BR><B>From:</B> 
  concurrency-interest-bounces@cs.oswego.edu 
  [mailto:concurrency-interest-bounces@cs.oswego.edu]<B>On Behalf Of </B>Nathan 
  Reynolds<BR><B>Sent:</B> Saturday, 18 August 2012 8:47 AM<BR><B>To:</B> 
  concurrency-interest@cs.oswego.edu<BR><B>Subject:</B> Re: 
  [concurrency-interest] Relativity of guarantees provided 
  byvolatile<BR><BR></FONT></DIV>
  <DIV class=moz-cite-prefix>> I have yet to meet a single Java professional 
  who wouldn't at least be very surprised to hear that the specification allows 
  this.<BR><BR>Add me to the list of surprised.<BR><BR>Here's an excerpt from 
  the specification.<BR><BR>A write to a volatile variable <A 
  href="http://docs.oracle.com/javase/specs/jls/se5.0/html/classes.html#36930">(8.3.1.4)</A> 
  <I>v</I> synchronizes-with all subsequent reads of <I>v</I> by any thread 
  (where subsequent is defined according to the synchronization order). 
  <BR><BR><A class=moz-txt-link-freetext 
  href="http://docs.oracle.com/javase/specs/jls/se5.0/html/memory.html#17.4.4">http://docs.oracle.com/javase/specs/jls/se5.0/html/memory.html#17.4.4</A><BR><BR>Doesn't 
  this mean that R will always read 1 since the read occurs after the 
  write?<BR><BR>
  <DIV class=moz-signature><A 
  href="http://psr.us.oracle.com/wiki/index.php/User:Nathan_Reynolds">Nathan 
  Reynolds</A> | Consulting Member of Technical Staff | 602.333.9091<BR><FONT 
  color=red>Oracle</FONT> <A href="http://psr.us.oracle.com/">PSR 
  Engineering</A> | Server Technology<BR></DIV>On 8/17/2012 2:24 PM, Marko 
  Topolnik wrote:<BR></DIV>
  <BLOCKQUOTE cite=mid:B7C5CC7B-6488-43F8-A72B-A808F3D0C051@inge-mark.hr 
  type="cite"><PRE wrap="">Consider the following synchronization order of a program execution involving a total of two threads, R and W:

- thread R begins;

- thread R reads a volatile int sharedVar several times. Each time it reads the value 0;

- thread R completes;

- thread W begins;

- thread W writes the sharedVar several times. Each time it writes the value 1;

- thread W completes.

Now consider the wall-clock timing of the events:

- thread R reads 0 at t = {1, 4, 7, 10};
- thread W writes 1 at t = {0, 3, 6, 9}.

As far as the Java Memory Model is concerned, there is no contradiction between the synchronization order and the wall-clock times, as the JMM is wall-clock agnostic. However, I have yet to meet a single Java professional who wouldn't at least be very surprised to hear that the specification allows this.

I understand that the SMP architecture that dominates the world of computing today practically never takes these liberties and makes the volatile writes visible almost instantaneously. This may change at any time, however, especially with the advent of massively parrallel architectures that seem to be the future. For example, an optimization technique may choose to chunk many volatile writes together and make them visible in a single bulk operation. This can be safely done as long as there are no intervening read-y actions (targets of the synchronizes-with edges as defined by JLS/JSE7 17.4.4).

Now, my questions are:

1. Is there a loophole in my reasoning?

2. If there is no loophole, is there anything to worry about, given that practically 100% developers out there consider as guaranteed something that isn't?


-Marko




_______________________________________________
Concurrency-interest mailing list
<A class=moz-txt-link-abbreviated href="mailto:Concurrency-interest@cs.oswego.edu">Concurrency-interest@cs.oswego.edu</A>
<A class=moz-txt-link-freetext href="http://cs.oswego.edu/mailman/listinfo/concurrency-interest">http://cs.oswego.edu/mailman/listinfo/concurrency-interest</A>
</PRE></BLOCKQUOTE><BR></BLOCKQUOTE></BODY></HTML>