The Cilk-M Project

From SuperTech Wiki

Cilk-M

In a dynamically multithreaded (dthreaded for short) language such as Cilk, since multiple children of a function may exist simultaneously, the runtime system employs a cactus stack to support multiple stack views for all the active children simultaneously. In all known software implementations of cactus stacks, however, transitioning from serial code (using a linear stack) to parallel code (using a cactus stack) is problematic, because the type of stack impacts the calling conventions used to allocate activation frames and pass arguments. One could recompile the serial code to use a cactus stack, but this strategy is not feasible if the codebase includes legacy or third-party binaries for which the source is not available. We call the property of allowing arbitrary calling between parallel and serial code --- including especially legacy (and third-party) serial binaries --- serial-parallel reciprocity, or SP-reciprocity for short.

It turns out that there seems to be an inherent trade-off between supporting SP-reciprocity and maintaining good time and space bounds, and existing work-stealing concurrency platforms fail to satisfy at least one of these three criteria.[1] We refer to the problem of simultaneously achieving all three criteria as the cactus-stack problem. Arch Robison, the main architect of Thread Building Blocks (Intel) and the current maintainer of Cilk Plus runtime system (Intel)[2], calls the cactus-stack problem a "Grand Challenge," because the incompatibility of cactus stacks and linear stacks impedes the acceptance of dthreaded languages for mainstream computing.

Cilk-M solves the cactus-stack problem by providing a memory abstraction that allows each of the multiple extant child functions to see its own view of the linear stack, even though they share the same parent. Thus, a function can operate on the cactus stack like it is a linear stack.

The Cilk-M System

There are three major components to the Cilk-M system:

References

↑ Java-based concurrency platforms do not suffer from the same problem with SP-reciprocity, because they are byte-code interpreted by a virtual-machine environment.

↑ Both Thread Building Blocks and Cilk Plus are examples of dthreading concurrency platforms.