www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Threads in language?

reply 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
Nov 05 2005
parent 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
Nov 06 2005