The Fortress Language Specification - CiteSeerX

the meaning of a program; it is simply an aid to enable the implementation to make informed decisions about data
placement.
It may not be possible for an object or a thread to reside in any possible region. The execution level of the region
hierarchy is where threads of execution reside, and is generally the bottommost level in the region tree. A thread is
generally associated with some region at the execution level, where that spawned thread will preferentially be run.
The programmer can affect the choice of region by using an at expression (Section 32.7) when the thread is created.
A spawned thread may be assigned a region higher in the region hierarchy than the execution level, either because
a higher region was requested or because scheduling decisions permit the thread to run in several possible execution
regions. The region to which a thread is assigned may also change over time due to scheduling decisions. The region
method for the object associated with a spawned thread returns the region of the associated thread.
The memory level of the region hierarchy is where individual reference objects reside; on a machine with nodes
composed of multiple processor cores sharing a single memory, this will not generally be the leaves of the region
hierarchy. Imagine a constructor for a reference object is called by a thread residing in region r , yielding an object o .
Except in very rare circumstances (for example when a local node is out of memory) either r.isLocalTo(o.region) or
(o.region).isLocalTo(r) ought to hold: data is allocated locally to the thread which runs the constructor. For a value
object v being manipulated by a thread residing in region r either (v.region).isLocalTo(r) or r.isLocalTo(v.region)
(value objects always appear to be local).
Note that region is a getter method and can be overridden like any other method. The chief example of this is arrays,
which are generally composed from many reference objects; the region method is overridden to return the location of
the array as a whole—the region which contains all of its constituent reference objects.
32.2 Distributed Arrays
Arrays, vectors, and matrices in Fortress are assumed to be spread out across the machine. As in Fortran, Fortress
arrays are complex data structures; simple linear storage is encapsulated by the HeapSequence type, which is used
in the implementation of arrays (see Section 32.7). The default distribution of an array is determined by the Fortress
libraries; in general it depends on the size of the array, and on the size and locality characteristics of the machine
running the program. For advanced users, the distribution library (introduced in Section 32.5) provides a way of
combining and pivoting distributions, or of redistributing two arrays so that their distributions match. Programmers
should create arrays by using an array comprehension (Section 13.29) or an aggregate expression (Section 13.28). The
operational internals of array comprehensions are described in Section 32.8.
Because the elements of a fortress array may reside in multiple regions of the machine, there is an additional method
a.region(i) which returns the region in which the array element a i resides. An element of an array is always local
to the region in which the array as a whole is contained, so (a.region(i)).isLocalTo(a.region) must always return
true . When an array contains reference objects, the programmer must be careful to distinguish the region in which the
array element a i resides, a.region(i) , from the region in which the object referred to by the array element resides,
a i .region . The former describes the region of the array itself; the latter describes the region of the data referred to by
the array. These may differ.
32.3 Abortable Atomicity
Fortress provides a user-level abort() function which abandons execution of an atomic expression and rolls back
its changes, requiring the atomic expression to execute again from the beginning. This permits an atomic section to
perform consistency checks as it runs. However, the functionality provided by abort() can be abused; it is possible
to induce deadlock or livelock by creating an atomic section which always fails. Here is a simple example of a
program using abort() which is incorrect because Fortress does not guarantee that the two implicit threads (created
216