Java Memory Model versus dotnet Memory Model

classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

Java Memory Model versus dotnet Memory Model

serge masse
Hi all,
Can someone give us a brief comparison (or a link)
between Java Memory Model and .NET Memory Model?

I am also more specifically interested in the
capabilities of a well constructed multithreaded
application in Java 5 and dotnet for working properly
on a multicore cpu.

For example, is it true that dotnet cannot guarantee
proper behavior of a multithreaded application on a
multicore chip?

And is it true that older version of Java, such as
Java 1.3 and older, cannot guarantee proper behavior
of a multithreaded application on a multicore chip?

thanks,
serge masse
_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

Re: Java Memory Model versus dotnet Memory Model

Jeremy Manson
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:

http://msdn.microsoft.com/msdnmag/issues/05/10/MemoryModels/default.aspx

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
[hidden email]
http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

Re: Java Memory Model versus dotnet Memory Model

Osvaldo Pinali Doederlein
Hi,

This excellent post (from Microsoft's JIT program manager) is a very
good overview of this issue:

http://discuss.develop.com/archives/wa.exe?A2=ind0203B&L=DOTNET&P=R375

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.

A+
Osvaldo

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:
>
> http://msdn.microsoft.com/msdnmag/issues/05/10/MemoryModels/default.aspx
>
> 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
> [hidden email]
> http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest
>
>


--
-----------------------------------------------------------------------
Osvaldo Pinali Doederlein                   Visionnaire Inform├ítica S/A
[hidden email]                http://www.visionnaire.com.br
Arquiteto de Tecnologia                          +55 (41) 337-1000 #223

_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

Re: Java Memory Model versus dotnet Memory Model

Jeremy Manson
Osvaldo Pinali Doederlein wrote:

> Hi,
>
> This excellent post (from Microsoft's JIT program manager) is a very
> good overview of this issue:
>
> http://discuss.develop.com/archives/wa.exe?A2=ind0203B&L=DOTNET&P=R375
>
> 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.
>
> A+
> Osvaldo
>

I'm not sure how excellent this article is.  For example, his LazyInit
example ignores reordering by the reader.  Even with the rules he
states, you would really need a memory barrier before the first read of
the singleton.

Having said that, the post is 3 years old and describes the ECMA
standard, which we know they are ignoring.  So it may not be all that
useful in understanding what they are doing now.

                                        Jeremy
_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

Re: Java Memory Model versus dotnet Memory Model

serge masse
In reply to this post by Jeremy Manson
Jeremy,
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
statements.

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.

thanks
serge

--- Jeremy Manson <[hidden email]> 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:
>
>
http://msdn.microsoft.com/msdnmag/issues/05/10/MemoryModels/default.aspx

>
> 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
> [hidden email]
>
http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest
>
_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

RE: Java Memory Model versus dotnet MemoryModel

David Holmes
> 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.)

There are two kinds of guarantee here:

a) what does the Java platform guarantee
b) what does a specific implementation of Java provide on a given platform

For (a) then pre Java 5 - yes certain idioms and coding practices are
technically incorrect and not guaranteed to work by the rules of the
platform.

However for (b) a given implementation is always more constrained than the
spec and actually provides tighter behaviour. For example, I believe that
Sun's JDK 1.4.2 implements volatile semantics in a way that is consistent
with the Java 5 memory model.

Depending on what kind of "guarantee" you are after, you may be able to use
pre Java 5 software in its existing form.

Given that multi-core chips are supposed to be transparent to the software
(ie the software can't tell if it is running on multi-core or SMP) then I
don't expect to suddenly see problems with software that ran on a SMP before
and is now run on multi-core. Of course, software that has only run on a
single processor before may well exhibit previously undetected concurrency
bugs when run with multiple processors and/or cores.

David Holmes

_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

RE: Java Memory Model versus dotnet MemoryModel

serge masse
David Holmes wrote: "Given that multi-core chips are
supposed to be transparent to the software (ie the
software can't tell if it is running on multi-core or
SMP) then I don't expect to suddenly see problems with
software that ran on a SMP before and is now run on
multi-core. Of course, software that has only run on a
single processor before may well exhibit previously
undetected concurrency bugs when run with multiple
processors and/or cores."

Thank you David.

Should we worry about multicores soon to be
ubiquitous?

Let's just consider servlets (and jsps) for example.

There are millions of them currently running.

A large portion of them are currently running on
uniprocessors and probably most of these are slated to
be ported to multicore systems over the next few
years.

What is the expected percentage of these that will
show new defects when ported to multicore?

I am worried by this but maybe I shouldn't be.
Nevertheless, there are quite a few signals raising
alarms about the issue of concurrent Java code ported
from uniprocessors to multicore and I hope that this
mailing list will be helpful about it, as I think it
is part of its purpose.

Thank you for all who make this list so informative
and useful.

serge

_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

Re: Java Memory Model versus dotnet MemoryModel

tpeierls
serge masse wrote:

> Let's just consider servlets (and jsps) for example.
>
> There are millions of them currently running.
>
> A large portion of them are currently running on uniprocessors and probably most of these are
> slated to be ported to multicore systems over the next few years.
>
> What is the expected percentage of these that will show new defects when ported to multicore?
>
> I am worried by this but maybe I shouldn't be.


I'm more worried about the ones that have defects but don't show them. These are the buffer
overruns of the Java world.

You can try to provide tools to increase confidence in the correctness of a program, but
programmers have to know enough to use these tools (and often have to get approval to use them).
So education is needed, and that's a long process.

--tim

_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

Re: Java Memory Model versus dotnet MemoryModel

serge masse
Thanks Tim.

--- Tim Peierls <[hidden email]> wrote:
>
> I'm more worried about the ones that have defects
> but don't show them. These are the buffer
> overruns of the Java world.

Indeed, I was implying that my understanding of
David's comment was when a multithreaded app is ported
from uniprocessor to a multicore, the new defects that
will manifest themselves should be virtuall all from
pre-existing defects in the original versions that had
not shown up on uniprocessor.

>
> You can try to provide tools to increase confidence
> in the correctness of a program, but
> programmers have to know enough to use these tools
> (and often have to get approval to use them).
> So education is needed, and that's a long process.
>
> --tim
>
 
I agree and like most Java consultants, a significant
percentage of my income is derived from such
educational work and this is also why I need to get
this issue straight, so that I can continue to do a
decent job advising my clients, as well as to continue
writing better code myself. A *train the
trainer-programmer* situation.

Do you have any specific tools to suggest for this
potential problem of porting concurrent apps from
uniprocessors to multicore?

thanks again,
serge
_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

Re: Java Memory Model versus dotnet MemoryModel

Brian Goetz
In reply to this post by serge masse
> Should we worry about multicores soon to be
> ubiquitous?

I think what Serge is getting at here is that the fact that
single-processor machines have been the norm in a lot of environments,
especially on desktops, has masked a lot of bugs, which may soon be
unmasked as the MP machines become cheaper and more widespread.

This is true, but I think a bigger masking factor is the dominance of
IA32 in the low-end multiprocessor world, whose stronger memory model
also masks a lot of real concurrency bugs.

> There are millions of them currently running.

And most are stateless, another masking factor.  The servlets that are
most likely to show thread-safety problems are also those that are most
likely to show other logic errors, such as those that implicitly assume
that the user will never hit the "back" button.  These are the ones that
carry state from request to request.

In other words, yes, the increased chance that a program will be
deployed on an MP system will disclose more bugs.  But there is a lot of
"noise" that may continue to mask these bugs, so I doubt it will be the
flood that some predict.  It might be better if it were a flood, because
then people would take it seriously (and some of us on this list could
make a fortune cashing in on the "next Y2K panic".)

> A large portion of them are currently running on
> uniprocessors and probably most of these are slated to
> be ported to multicore systems over the next few
> years.

Except that there will be no "porting", just redeploying.  Porting
involves a managed effort to audit, modify, and test.  More likely,
people will buy new systems and slap them in their racks.

>
> What is the expected percentage of these that will
> show new defects when ported to multicore?
>
> I am worried by this but maybe I shouldn't be.
> Nevertheless, there are quite a few signals raising
> alarms about the issue of concurrent Java code ported
> from uniprocessors to multicore and I hope that this
> mailing list will be helpful about it, as I think it
> is part of its purpose.
>
> Thank you for all who make this list so informative
> and useful.
>
> serge
>
> _______________________________________________
> Concurrency-interest mailing list
> [hidden email]
> http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest

_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest