Assaf Schuster wrote:
> CONCLUSION1: Anything more relaxed than SC for JMM will result in
> degredation of performance for the "average" multithreaded Java
program.
I don't see the validity in this argument.
First your average Java programmer doesn't know threading - they know that
Java has threads. The two are most definitely not the same thing.
When a Java programmer is taught about threading and synchronization they
will tend to over synchronize as a natural tendency toward safety. This is
not a bad thing. Most Java programmers do not work on systems where
synchronization is going to be the defining bottleneck in the system.
For some systems synchronization (or rather over-use of) will be a problem.
To identify this problem requires skills in profiling and measurement that
your average Java programmer does not have. To play in this arena you need
to move up in the knowledge department.
Understanding when you can remove redundant synchronization and when you can
use alternatives to synchronization is also a higher knowledge arena - as
you also state. Most programmers won't play here - your average programmer
can't play here.
I don't see how requiring SC is going to change any of this unless you are
advocating that we use SC so that naive programmers who don't use any form
of synchronization will at least be able to reason about some part of their
incorrect program when it fails. Further, use of SC on systems which don't
use SC at the hardware level will require lots of additional memory barriers
- more than with correctly synchronized programs - and so performance will
be even worse.
Now maybe you are arguing for non relaxed memory models at the hardware
level - that's fine. But that's a bit out of scope for what is being done
with the JMM.
I do agree, however, that we should have some quantitative measures of how
the proposed JMM will affect performance in different situations on
different architectures.
David Holmes
-------------------------------
JavaMemoryModel mailing list - http://www.cs.umd.edu/~pugh/java/memoryModel
This archive was generated by hypermail 2b29 : Thu Oct 13 2005 - 07:00:33 EDT