| C-- | Harvard EECS
|
| C-- Home | Specification & Downloads | Old News | Papers | Mailing List | People | FAQ |
Here, then, is the problem we address: we want to make it easy for a front end to support efficient user-level threads, in such a way that all the policy decisions are in the hands of the front end, while all the tricky mechanism is supported by C--. Like many fine phrases, this goal is easier to state than achieve. The contribution of this paper is a design that extends C-- with clean, architecture-independent mechanisms that can be used to im One high-level run-time service that a C-- client might want to offer is concurrency. Little or no direct support is necessary to use facilities provided by the operating system: processes and threads. All we need is the ability to call the APIs provided for these facilities.
Sometimes, though, we want really lightweight concurrency, where we have hundreds or thousands of logical threads. Examples of languages that require this support are Concurrent ML, Concurrent Haskell, Silk, and perhaps Java.
It would be unreasonably expensive to create so many operating-system threads, so we want the ability to multiplex multiple logical threads onto a single operating-system thread. Terminology: we will call a logical, lightweight thread a C-- thread, or just thread; we will call an operating system thread an OS thread, or sometimes worker thread.
This document describes the facilities that C-- offers to support lightweight concurrency. In each section we have a sub-section ``Implementation notes''. This gives suggestions for how a C-- implementation might implement the C-- runtime interface described in that section. But they are only suggestions: the client cannot assume anything beyond what the specification of the runtime interface says. Nevertheless, it is important to have some degree of confidence that the interface is indeed implementable!