The definition variable method essentially eliminates the barriers from the barrier implementation. Hence, the waiting time at the the reply receive point is the same as in the barrier implementation, as is the number of messages sent (a request message and a reply message). Barriers are eliminated at the cost of compile time allocated extra memory (as compared to the barrier implementation) for definition variables and runtime allocated extra memory and extra time for internally queuing early requests. Runtime allocated memory is bounded by the maximum number of early requests possible at any given time. Since there can only be a single early request from each processor, the maximum number of early requests possible is P-1 where P is the number of processors. In practice, this limit is fairly small, and is rarely reached. The amount of memory used by definition variables can be bounded at compile time by specifying the desired looseness of synchronization. Clearly, more memory buys a looser synchronization requirement. In the code shown in the previous subsection, a barrier is executed after every K iterations. In general, if the difference between the current iteration of the fastest thread and that of the slowest thread is always less than K, no synchronization is necessary. Only when the difference is greater than K is synchronization necessary. Fuzzy barriers[Gup89] can be used to implement this type of dynamically imposed synchronization. The implementation is straightforward and is omitted.