The Fortress Language Specification - CiteSeerX

y evaluating the two elements of the tuple) will always run in parallel; it is possible for the first element of the tuple
to continually abort without ever running the second element of the tuple:
r : Z64 := 0
(a, b) = (atomic if r = 1 then 17 else abort() end,
do r := 1; r end)(∗ INCORRECT! ∗)
Fortress also includes a tryatomic expression, which attempts to run its body expression atomically. If it succeeds,
the result is returned; if it aborts due to a call to abort , the AtomicAborted exception is thrown; if it aborts due to
conflict (as described in Section 13.23), the AtomicConflict exception is thrown. These exceptions both implement
the AtomicFailed trait, which is an instance of CheckedException. Conceptually atomic can be defined in terms
of tryatomic as follows:
label AtomicBlock
while true do
try
result = tryatomic body
exit AtomicBlock with result
catch e
AtomicFailed ⇒ ()(∗ continue execution ∗)
end
end
throw UnreachableCode(∗ inserted for type correctness ∗)
end AtomicBlock
Unlike the above definition, an implementation may choose to suspend a thread running an atomic expression which
invokes abort , re-starting it at a later time when it may be possible to make further progress. The above definition
restarts the body of the atomic expression immediately without suspending.
32.4 Shared and Local Data
Every object in a Fortress program is considered to be either shared or local (collectively referred to as the sharedness
of the object). A local object must be transitively reachable (through zero or more object references) from the variables
of at most one running thread. A local object may be accessed more cheaply than a shared object, particularly in the
case of atomic reads and writes. Sharedness is ordinarily managed implicitly by the Fortress implementation. Control
over sharedness is intended to be a performance optimization; however, methods such as isShared and localize can
affect program semantics, and must be used with care.
The sharedness of an object should be contrasted with its region. The region of an object describes where that object
is located on the machine. The sharedness of an object describes whether the object is visible to one thread or to many.
A local object need not actually reside in a region near the thread to which it is visible (though ordinarily it will).
The following rules govern sharedness:
• Reference objects are initially local when they are constructed.
• The sharedness of an object may change as the program executes.
• If an object is currently transitively reachable from more than one running thread, it must be shared.
• When a reference to a local object is stored into a field of a shared object, the local object must be published:
Its sharedness is changed to shared, and all of the data to which it refers is also published.
• The value of a local variable referenced by a thread must be published before that thread may be run in parallel
with the thread which created it. Values assigned to the variable while the threads run in parallel must also be
published.
217