Cliff Click wrote:
> The issue is wheither any interesting program can have some nearby locks
> that are candidates for coarsening, the locks are only lightly contented
> but are heavily used so that any coarsening causes a lot of contention.
> And, of course, it's only coarsening that does you in; moving to next
> year's machine where N is 2x larger somehow doesn't make these locks get
> all hot & contended. I'll hand-wave and claim this set of programs is
> fairly small. :-)
>
> I'll even hand-wave a solution: if the coarsened lock gets contended,
> HotSpot can recompile with the coarsening turned off for those locks.
Perhaps this is also mitigated by the prospect of JSR-166 having real R/W
locks that can be natively implemented and not consist of nearby
synchronized regions and hence not be subject to coarsening ?
My problem with playing around with the contents of synchronized blocks may
be more of an academic one than a practical one. But it seems to me that
reasoning about the behaviour of programs is hard enough when you know what
the code does, so reasoning about concurrent programs when what you see in
the code is not what you get, becomes impossible. But if I'm the lone voice
that thinks this is a problem, then perhaps its not a problem afterall.
David
-------------------------------
JavaMemoryModel mailing list - http://www.cs.umd.edu/~pugh/java/memoryModel
This archive was generated by hypermail 2b29 : Thu Oct 13 2005 - 07:00:39 EDT