The kind of system you can make depends on the combined
capabilities of your operating system and processor. has been
developed in a solely Unix environment and this has considerably
warped its view of the world. So far, has only been ported to
different versions of Unix. A particular feature of is
support for multiple threads of control. Whether these do actually
execute concurrently depends on the host system, but, in principle, it
should be possible to develop a program using threads on one
system—perhaps a uni-processor simulating concurrency—and later
execute the same program on a multi-processor or a distributed
processor to achieve the same net result.
Broadly speaking, can be made in any of three main
configurations ...
- Generic
- Under the ``any'' machine configuration, attempts to be a fully portable ANSI C program. Because there is no
reliably portable method of implementing threads in C, the thread
operations in this mode are not available and only a serial version of
remains. This mode is most suitable for getting started
quickly and also the most sensible place to begin for porting to new
architectures or operating systems. Memory use is minimised which may
benifit smaller machines such as PCs or any system where memory is at
a premium.
- BSD
- This (badly named) configuration mode requires that a stack
switching operation be available for to use. Given this code
(typically a few lines of the local assembler), the thread operations
become available with the limitation that only one thread is run at a
time. This mode allows programs to be written in terms of threads
which may later be run in parallel without alteration. This mode is
most useful for allowing the developing multi-threaded applications
under unsupportive operating systems such as BSD 4.2 or 4.3.
- System V
- This configuration requires that stack switching code
be available along with the standard System V shared memory
manipulation primitives. Given these things becomes a truly
parallel multi-threaded system using the following model: on start-up
a piece of shared memory is allocated, then forks as many times
as there are physical processors in the host machine (this behaviour
may be modified). Each of these forked processes runs the scheduler, running threads from the pool in the shared heap. Each
such thread is run to conclusion—unless it yields control, in which
case it will be returned to the pool. More processes may be forked
than existing processors to simulate truly parallel operation on
uniprocessor systems such as Suns running SunOS 4.1.