[concurrency-interest] Java Memory Model versus dotnet Memory Model

Jeremy Manson jmanson at cs.purdue.edu
Wed Nov 2 19:18:01 EST 2005

Gnah.  CLI stuff...

We have been back and forth with the .NET people about this a few times. 
  My understanding is that .NET ignores the ECMA CLI specification 
memory model.  This is no bad thing, because although it learned some of 
the lessons of the JMM, it didn't learn all of them.  It was quite 
vague.  However, this means that we are somewhat light on documentation 
on what .NET actually does.

I note that Vance Morrison has recently posted an article on the new 
model in the .NET Framework 2.0:


It is a fairly weak (in the memory consistency sense) model.  From a 
quick glance, it looks as if it doesn't deal with a lot of the subtle 
issues that we dealt with in the JMM.  This is of more interest to 
compiler writers than the people on this list, though.

As for the relative correctness of your code on .NET and in earlier 
versions of Java, that depends on your code.

In JDK1.4 and earlier, and, I suspect, in .NET, if you use locks 
correctly, then your code will behave correctly.  By use locks 
correctly, I mean that all accesses to shared memory should be ordered 
by locking and mutual exclusion (more accurately, the locks in your 
program should ensure that there should be no data races).

If you don't follow this locking protocol (using volatiles, for 
example), you can get into trouble in earlier JDKs.  .NET has a volatile 
modifier which, I believe, is intended to work like Java's.


More information about the Concurrency-interest mailing list