Future Implementations

Currently Coir<Futures> implements futures using an extended form of the leapfrogging mechanism discussed in [24]. This mechanism combines leapfrogging with task stealing to achieve load balancing. Since this paper concentrates more on the generic programming interface aspect of the system, we do not describe the implementation details. It may be noted that due to the object-oriented nature of the system different implementations (depending on the underlying thread system and the hardware environment) may be supported without changing the interface.

There may be situations (like the one described in the example in the previous section) where future objects are created but are never resolved. The semantics and our implementation guarantees that the future value is made available at the point where it is required. However, futures may be scheduled and computed even if their values are not required. Consider the following example:

 future_pointer_to_unary_function<

				int,int>::future_type fval1

						 = (future_ptr_fun(foo))(4);

future_pointer_to_unary_function<

				int,int>::future_type fval2

						 = (future_ptr_fun(foo))(5);

		

		int x = fval1;

		fval2 is never resolved

		x is never used

This program creates two future computations fval1 and fval2. fval2 is never resolved while fval1 is resolved to an integer variable x, but the resolved variable x is never used. Most optimizing C++ compilers which performs extensive flow analysis may be able to eliminate dead code of this kind. In compiler terms, x and fval2 are dead variables and their computation may be eliminated if other conditions like absence of side effects in their computation are satisfied. Coir<Futures> does not make any special effort to avoid scheduling dead futures. We rely on the C++ compiler for such optimizations. The compiler may not be able to eliminate all cases of dead futures. For instance, the ones in the example in the previous section are embedded in a list and are harder for the compiler to identify.