• Lucas (7/7) Nov 05 2005 I just came across this paper and found it kind of interesting:
• Sean Kelly (42/50) Nov 06 2005 D is in fairly good shape in this regard, as it does define some

Lucas <lgoss007 yahoo.com> writes:

I just came across this paper and found it kind of interesting:
http://www.hpl.hp.com/techreports/2004/HPL-2004-209.html

Along with a discussion I found elsewhere:
http://www.opengroup.org/austin/mailarchives/ag/msg08719.html

Well I don't have quite enough experience in this subject area, so I was
wondering what your opinions are on this. Anyone?

Lucas

Sean Kelly <sean f4.ca> writes:

Lucas wrote:
 I just came across this paper and found it kind of interesting:
 http://www.hpl.hp.com/techreports/2004/HPL-2004-209.html
 
 Along with a discussion I found elsewhere:
 http://www.opengroup.org/austin/mailarchives/ag/msg08719.html
 
 Well I don't have quite enough experience in this subject area, so I was
 wondering what your opinions are on this. Anyone?

D is in fairly good shape in this regard, as it does define some 
concurrent semantics in language.  Of particular note is the volatile 
statement.  Based on the paper however, this may not be enough.  The 
ptertinent example is that:

if (x == 1) ++y;
if (y == 1) ++x;

can be transformed to:

++y; if (x != 1) --y;
++x; if (y != 1) --x;

without violating the D memory model (as far as I know).  This is why 
Java allows variables to be declared as volatile--to prevent odd 
optimizations that may change behavior with concurrent access.  I'm not 
sure this can be prevented in-language with D:

volatile { if (x == 1) ++y; }
volatile { if (y == 1) ++x; }

can still be transformed to:

volatile { ++y; if (x != 1) --y; }
volatile { ++x; if (y != 1) --x; }

in D, as the spec says nothing about optimizations within the volatile 
statement itself.  I think this could be prevented by writing the blocks 
differently:


if (x == 1) volatile ++y;
if (y == 1) volatile ++x;

though I suppose this could still be optimized to:

if (x == 1) { --y; y += 2; }
if (y == 1) { --x; x += 2; }

without altering behavior for a single-threaded virtual machine.

It might be enough to simply change the spec here, so any instructions 
within volatile are not optimized, so predictable sequential behavior is 
preserved when needed.  Beyond that, I'm sure Walter is keeping an eye 
on the C+ standardization process, so if anything useful comes out of 
the work there, you can bet it will make its way into D somehow.

Another point of interest is that D has in-language support for assembly 
code, so library writers can avoid a lot of these problems whether the 
spec has a concurrent memory model or not.  The atomic module in Ares, 
for example, should allow for correct lock-free code in D:

http://svn.dsource.org/projects/ares/trunk/src/ares/std/atomic.d

It would be nice if this sort of thing were supported in-language, but 
I'm not sure of the best way to do it... and neither are the C++ folks. 
  Hopefully they'll work out something reasonable in the next year.


Sean