next up previous
Next: Construction of LoopWorker_x Up: Actual Loop Parallelization Previous: Actual Loop Parallelization

Construction of run_x()

  First, depending on whether myMethod() is a class method or an instance method, the restructuring compiler adds the following class or instance method run_x() to MyClass, where body(i) denotes a literal copy of the original loop-body. The l1...lp (with corresponding types typei) denotes the set of local variables and parameters of myMethod() that are referred to within body(i), but that are declared outside the loop Li:

tabular304

Class and instance variables, the loop index i, and all other variables declared within the loop remain visible in run_x(). Hence, if the value of every li remains unaltered in the loop-body, the original loop can be executed in parallel by letting different threads invoke this method for different subsets of iterations and providing the appropriate value of each li as argument.

If, on the other hand, the value of any li itself may change (not counting changes to elements or fields of an array or object reference li), there is not likely much parallelism in the loop and the compiler simply resorts to disabling the loop parallelization to prevent the requirement to propagate such changes back to the main thread.

For DOACROSS-like execution, the compiler adds the appropriate synchronization primitives to the loop-body according to methods described in the literature [19, 20, 21, 22, 37]). Setting the bit of iteration i of a synchronization with number k is implemented as `sync_x[k].doPost(i)'. Likewise, waiting for the bit of iteration j of the synchronization variable with number k to become set is implemented as `sync_x[k].doWait(j)'.



ajcbik@extreme.indiana.edu