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
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
The result is both a reduction in the number of synchronizations that
can be eliminated and an increase in compile complexity and run time.
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 email@example.com 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