Steve Kautz wrote:
> > Now the inner loop is known to be short duration, so fusing the lock
> > with itself:
> >
> > for( int i = 0; i < 1bazillion; i+=8 ) {
> > sync(global_lock) {
> > for( int j = 0; j < 8; j++ ) {
> > obtain psuedo random # and update seed under lock
> > simulate_using_psuedo_random_value
> > }
> > }
> > }
>
> It seems to me that making decisions like this about the level of
> granularity for holding locks should be under the programmer's control.
> There is no way to expect a compiler to, e.g., analyze the execution time of
> a synchronized block in a loop body and decide when it is "reasonable" to
> fuse them.
I absolutely disagree. This kind of code happens all the time "by accident",
due to inlining or 3rd party libraries or what-not. Denying the compiler
this opportunity is denying an easy fix to un-intended heavy sync costs.
If fact it's easy to analyze the execution time of many common cases
and the compiler can "reasonably" figure out when to do it often enough
(or maybe said more clearly: the compiler can figure out when it's
"reasonable" to do it often enough, because the compiler can prove the
loop body work is trivial).
We're not trying to build a hard-real-time standard here. There should be
only soft limits on how long we can stretch a lock; if we provide some
fairness at a granularity that looks good to a GUI (10 to 100's a second)
I think everybody will like the results. Folks looking for hard guarentees
about time need to go jump on the hard-real-time Java bandwagon.
Cliff
-- Cliff Click Compiler Designer and Researcher cliffc at acm.org Java Software (408) 863-3266 MS UCUP02-302------------------------------- 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