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

serge masse sergemasse1 at yahoo.com
Thu Nov 3 19:26:27 EST 2005

Thank you very much for the link and info that you
provided in your reply. They were very useful and also
guided me in further search and some refinement of my
previous statements.

I would appreciate if you or someone else could
correct, confirm, or invalidate the following 2

1) In order to come up with a well constructed
multithreaded Java app guaranteed to work properly on
any multicore chips when using Java 1.4 down, one must
consider as invalid certain idioms and advices from
Sun and others, and use the old Ada and Modula3
technique of synchronizing all accesses to shared
variables, including those qualified as final and
including those of type String. (The situation is
better, i.e., less restrictive and allowing better
performance, when using Java 5.)

2) Dotnet cannot guarantee proper behavior of a
multithreaded application on all multicore chips and
can only be safely used on the multicore chips that
are officially supported by Microsoft. 


--- Jeremy Manson <jmanson at cs.purdue.edu> 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.
> 					Jeremy
> _______________________________________________
> Concurrency-interest mailing list
> Concurrency-interest at altair.cs.oswego.edu

More information about the Concurrency-interest mailing list