The Fortress Language Specification - CiteSeerX

(discussed in Section 13.13) to a surrounding label (the label is considered to be out of scope), but may fail to catch an
exception and thus complete abruptly. When this happens, the exception is deferred. Any invocation of the val method
on the spawned thread throws the deferred exception. If the spawned thread object is discarded, the exception will be
silently ignored. In particular, if the result of a spawn expression is dropped, it is impossible to detect completion of
the spawned thread or to recover from any deferred exceptions.
The wait method waits until the thread is complete and then returns the void value. The ready method does not wait,
but instead returns a boolean value indicating whether the thread is complete. Invocations of these methods do not
cause deferred exceptions to be thrown.
We say a spawned thread has been observed to complete after invoking the val or wait methods, or when an invocation
of the ready method returns true .
There are three ways in which a thread can be suspended. First, a thread that begins evaluating an implicitly parallel
construct is suspended until the thread group has completed. Second, a thread that invokes val or wait is suspended
until the spawned thread is complete. Finally, invoking the abort function from within an atomic expression may
cause a thread to suspend; see Section 32.3.
Threads in a Fortress program can perform operations simultaneously on shared objects. In order to synchronize data
accesses, Fortress provides atomic expressions (see Section 13.23). Chapter 21 describes the memory model which
is obeyed by Fortress programs.
Different implicit threads (even different iterations of the same loop body) may execute in very different amounts
of time. A naively parallelized loop will cause processors to idle until every iteration finishes. The simplest way to
mitigate this delay is to expose substantially more parallel work than the number of underlying processors available to
run them. Load balancing can move the resulting (smaller) units of work onto idle processors to balance load.
The ratio between available work and number of threads is called parallel slack [3, 4]. With support for very
lightweight threading and load balancing, slack in hundreds or thousands (or more) proves beneficial; very slack
computations easily adapt to differences in the number of available processors. Slack is a desirable property, and the
Fortress programmer should endeavor to expose parallelism where possible.
4.5 Environments
An environment maps names to values or locations. Environments are immutable, and two environments that map
exactly the same names to the same values or locations are identical.
A program starts executing with an empty environment. Environments are extended with new mappings by variable,
function, and object declarations, and functional calls (including calls to object constructors). After initializing all
top-level variables and singleton objects as described in Section 22.6, the top-level environment for each component is
constructed.
The environment of a value is determined by how it is constructed. For all but object expressions, function expressions
and local function declarations, the environment of the constructed value is the top-level environment of the component
in which the expression or declaration occurs. For object and function expressions and local function declarations, the
environment of the constructed value is the lexical environment in which the expression or declaration was evaluated.
We carefully distinguish a spawned thread from its associated spawned thread object. In particular, note that the
execution environment of a spawned thread, in which the body expression is evaluated, is distinct from the environment
of the associated thread object, in which calls to the thread methods are evaluated.
39