During execution of a parallel loop, loop-workers compete
for work by accessing a shared pool of iterations,
as is illustrated in figure 4.
This structure of such a pool
is defined by the class LoopPool.
Two instance variables low and high are
used to represent the execution set 
of the parallel stride-1 loop, while the
instance variables numW and
sched are used to record the number of loop-workers and
a kind of scheduling policy.
Furthermore, the class provides
two administration variables blocksize
and count:
Figure 4: Execution of a Parallel Loop
In the only constructor of this class, initial values are assigned to all instance variables:
The next amount of work is obtained by calling instance method nextWork() on the pool. Depending on the kind of scheduling policy used, new values are assigned to the instance variables low, high, and stride of a loop-worker that is supplied in the parameter worker. If the pool has been exhausted, the method returns the value `false'. Because a pool is shared amongst all loop-workers of a particular parallel loop, mutual exclusion while updating shared data is enforced by making the method synchronized:
To obtain a uniform interface between loop-workers and a pool, in our framework the pre-scheduled policies are implemented as special versions of a self-scheduled policy, where each loop-worker directly obtains all work in the first call to nextWork() and terminates after the second call.