David Holmes wrote:
> Consider a simple example - using a read/write lock to allow concurrent
> reads of a shared data structure for searching:
> // lengthy search code
> The only real sync blocks occur in the acquire/release methods of the
> read/write lock. If those methods get inlined then the "smart" compiler may
> decide to merge the two sync blocks and totally kill the whole point of
> having read/write locks. Does this make sense to you? It certainly makes no
> sense to me! What prevents this from happening? Do we need rules to prevent
Does this make sense? No - lengthy search code will be "not obviously short"
and "quality of implementation" dictates that I do not stretch a lock across
not-short code. So - we don't need more rules to prevent it, the rule of
common sense should be sufficient! If it's not, switch VM's to HotSpot which
will keep common sense in mind. :-)
> I do not agree that fusing sync blocks is a desirable goal and in fact
> should be prohibited unless the sync itself can be shown to be redundant.
> Any "optimisations" such as loop unrolling, must respect the placement of
> sync blocks and maintain them. Could this lead to sub-optimal code? Probably
> in some cases. But I'd rather see new idioms for synchronization that
> account for possible loop unrolling by the compiler, than see compilers
> think they know how to deal with application level synchronisation!
"Probably, for some cases"???? More likely, sub-optimal for nearly all
cases, excluding code written by really competent people (many of which
are represented here). I routinely have to optimize code that would make
you gag; the average Java programmer is, well... average,
and a compiler gets to see _all_ the dirty underwear.
Anytime I coarsen a lock I will certainly keep issues like liveness foremost
in mind. But I really want to opportunity to do so, so I can rescue the 95%
of the code out there where 'synchronize' is obviously being overused.
JavaMemoryModel mailing list - http://www.cs.umd.edu/~pugh/java/memoryModel
This archive was generated by hypermail 2b29 : Thu Oct 13 2005 - 07:00:29 EDT