StackThreads/MP: version 0.77 User's Guide

11.1: Why am I interested in it?

Q: I am already accustomed to Pthreads, why must I use StackThreads/MP in the first place?

A: Pthreads and StackThreads/MP provide a similar set of basic primitives (thread create and synchronization). The most fundamental difference is that StackThreads/MP creates a thread very cheaply and tolerates a very large number of threads. This makes a significant difference in parallel programming styles.

In parallel programming with Pthreads, the programmer normally creates a constant number of threads and threads share a common task pool to distribute work (even more simply, each thread is statically assigned to a particular task at compile time). A piece of work is represented by a datum and it enters the task pool when it is found necessary. This explicit representation of a task is already onerous (Recall that in sequential programs, you simply call a function to perform a particular task. You don't have to define a data structure that represents a task). Worse, to achieve scalability, you are often forced to make the task pool concurrently accessible from multiple threads. This complicates the structure of the task pool, making overheads of queue manipulation larger and programming errors more likely. Most importantly, the resulting parallel program obscures the logic of the computation and looks very different from the sequential program, making the cost of maintenance significantly larger.

In parallel programming with StackThreads/MP, the programmer is encouraged to create threads dynamically when a piece of work is found necessary. It provides a primitive that attaches a thread to any procedure call in C and a thread creation costs only a little more than a sequential procedure call. The runtime system regards a thread as a unit of work and schedules whatever number of threads you created on whatever number of processors you have. Therefore, you need not manage a task pool explicitly. It is a library built on top of traditional thread libraries such as Pthreads. It internally spawns a fixed number of coarse-grain threads (i.e., threads in the Pthreads' sense) and each such thread creates arbitrary number of fine-grain threads (i.e., threads in StackThreads/MP's sense) and distributes them among the underlying coarse-grain threads. StackThreads/MP programming model is particularly attractive when starting from sequential source. Basically, some procedure calls in the sequential source are replaced by thread creations. In most cases, you can retain the overall structure of the sequential source. Everything comes from the fact that a thread creation is very cheap; therefore you do not worry about ``too much threads.''

There are some other reasons why you might be interested in StackThreads/MP.

• Portability among various parallel platforms. It encapsulates the underlying thread library.
• Stylized spin-locks: Tutorials of traditional thread libraries overly discourage spin-locks. They typically say ``never do that.'' But they are necessary for performance and safe as long as care must be taken so that all critical sections are very short. Traditional thread libraries have no support for spin-locks, making them onerous and error-prone.
• Tools: It provides a simple performance profiler so that you can reason about how is your parallel program running well.
• Memory management primitives: It provides efficient alternatives to malloc in the libc. malloc is often a source of bottleneck in parallel programs. Alternatives include a simple replacement of malloc that are much more scalable than the libc malloc, a parallel conservative garbage collector, and explicit memory management based on regions (a.k.a. zones).