[concurrency-interest] Java Memory Model versus dotnet Memory
Osvaldo Pinali Doederlein
osvaldo at visionnaire.com.br
Thu Nov 3 12:13:09 EST 2005
This excellent post (from Microsoft's JIT program manager) is a very
good overview of this issue:
Go straight to "CAVEATS for V1" in the end. Basically, it seems that
Microsoft gets away with a weak MM and implementation, because they
support mostly the P5/P6 platform which hardware MM is very strong.
So they can use all compiler optimizations they want without issues.
But IIRC the Intanium is not as nice as the Pentium, so I'd expect
MS to have improved this in .NET 2.0 which supports 64-bit platforms.
Jeremy Manson wrote:
> 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.
> Concurrency-interest mailing list
> Concurrency-interest at altair.cs.oswego.edu
Osvaldo Pinali Doederlein Visionnaire Informática S/A
osvaldo at visionnaire.com.br http://www.visionnaire.com.br
Arquiteto de Tecnologia +55 (41) 337-1000 #223
More information about the Concurrency-interest