Intel Threading Building Blocks

Recycling

Not only can you bypass the scheduler, you might be able to bypass task allocation and deallocation as well. This opportunity frequently arises for recursive tasks that do scheduler bypass because the child is initiated immediately upon return just as the parent completes. Example 9-9 shows the changes required to implement recycling in the scheduler bypass example.

Example 9-9. Scheduler bypass plus task alloc/dealloc bypass

struct FibTask: public task {
// was:    const long n;
    long n;
// was:    long* const sum;
    long* sum;
    ...
    task* execute() {
        if( n<CutOff ) {
            *sum = SerialFib(n);
            return NULL;
        } else {
            FibContinuation& c =
                *new( allocate_continuation() ) FibContinuation(sum);
            FibTask& a = *new( c.allocate_child() ) FibTask(n-2,&c.x);
            FibTask& b = *new( c.allocate_child() ) FibTask(n-1,&c.y);
            recycle_as_child_of(c);
            n -= 2;
            sum = &c.x;
            // Set ref_count to "two children".
            set_ref_count(2);
            c.spawn( b );
// was:     return &a;
            return this;
        }
    }
};

The child that was previously called a is now the recycled this. The call recycle_as_ child_of(c) has several effects:

• It marks this not to be automatically destroyed when execute returns.

• It sets the depth of this to be one more than the depth of c.

• It sets the dependent of this to be c. To prevent reference-counting problems, recycle_as_child_of has a prerequisite that this must have a NULL dependent. This is the case after allocate_continuation occurs.

When recycling, ensure that the original task’s fields are not used after the task might ...