According to David F. Bacon :
>
> Doug Lea writes:
> > As has been recently demonstrated (by, among others, V.C. Sreedhar
> > and IBM colleagues in their upcoming OOPSLA paper), many Java
> > programs are mostly single-threaded, and contain a lot of code that
> > can be statically determined as such. In a language where safety is
> > a primary goal, it seems wiser all around for compilers to remove
> > unnecessary synchronization and barriers than for programmers to do
> > so.
>
> Note however that the semantics of an unlock operation in the general
> case disallow removing the synchronization associated with the unlock,
> even if the object is thread-local.
>
> At an unlock *all* writes must be made globally visible, so to optimize
> away the synchronization the compiler must prove not only that the
> object is thread local, but also that there have been no intervening
> writes to shared variables (accessible without locking the object in
> question) since the last unlock. In the absence of such proof, you can
> eliminate the mutual exclusion operations but not the synchronization
> operation(s).
>
> The result is both a reduction in the number of synchronizations that
> can be eliminated and an increase in compile complexity and run time.
>
> david
>
I and David among others have dicussed this issue. I also chatted
with Bill Pugh when he visited IBM on this issue. The Java byte
code monitorexit has two purpose: (1) to behave as unlock so that
the thread can get out of critical section, (2) flushing of local
thread memory to main memory. So when we did our escape analysis
work, to ensure that semantics of Java is preserved we bypassed
the unlocking portion, but still flushing the local memory.
We also have a scheme where we can determine if we can safely remove
the flushing operation.
There is one more issue (first pointed to me by Chet Murthy)
that there is no way that we can have a debugger that can observe
multiple threads via print statements (since print is synchronized).
As soon a we insert a print statement we loose concurrency.
Sreedhar
-------------------------------
This is the JavaMemoryModel mailing list, managed by Majordomo 1.94.4.
To send a message to the list, email JavaMemoryModel@cs.umd.edu
To send a request to the list, email majordomo@cs.umd.edu and put
your request in the body of the message (use the request "help" for help).
For more information, visit http://www.cs.umd.edu/~pugh/java/memoryModel
This archive was generated by hypermail 2b29 : Thu Oct 13 2005 - 07:00:13 EDT