> > * At a point where a thread releases a lock (in the original
> > program), if another thread of equal or higher priority is waiting on
> > the lock, the other thread should be allowed to obtain (perhaps we
> > need to limited this to "compete for") the lock within a short
> > interval.
>
> Well, I hope not to be too cynical or pessimistic about this, but I
> am. Last I knew, there are JVM providers who absolutely will not
> accept such rules. (I believe that similar issues arose in POSIX.) I
> think the best we could hope for universal acceptance of is
> probablistic weak fairness. ("probablistic" because anything based in
> part on spinlocks will rely in part on effectively random hardware
> events.)
>
For example, any rule that relies at all on thread priority will immediately
disqualify a native-thread VM (e.g. JDK) running on NT; the priorities are
under control of the OS, which raises and lowers them somewhat whimsically.
But aside from that, I think that rule (*) still begs the question: who gets
to control when/whether unrolled loop segments can be fused. Looking at
Cliff's example,
> I understand your intent, but "loop unrollings should be allowed to fuse
> unrolled segments" looks like it contradicts Rule 2. Fer instance, if one
> runs over to SciMarks and looks at the MonteCarlo simulation, one
> sees stuff like:
>
> for( int i = 0; i < 1bazillion; i++ ) {
> sync(global_lock) {
> obtain psuedo random # and update seed under lock
> }
> simulate_using_psuedo_random_value
> }
>
.... Or perhaps do unroll-and-jam:
>
> for( int i = 0; i < 1bazillion; i+=8 ) {
> for( int j = 0; j < 8; j++ ) {
> sync(global_lock) {
> obtain psuedo random # and update seed under lock
> }
> simulate_using_psuedo_random_value
> }
> }
>
> 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.
--Steve K
-------------------------------
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