This section introduces distributed constructs that allow the programmer to extend pSather code with explicit placement information for efficiency on distributed pSather implementations. Explicitly placing objects and threads does not affect the semantics of the original code, but it is also possible to deliberately change the original flow of control (ie. using with-near on See with-near statement).
The memory performance model of pSather has two levels. The basic unit of location in pSather is the cluster. The programmer may assume that reading or writing memory on the same cluster is significantly faster than on a remote cluster. A cluster corresponds to an efficient group in the memory hierarchy, and may have more than one processor. For example, on a network of workstations a cluster would correspond to one workstation, although that workstation may have multiple processors sharing a common bus. This model is appropriate for any machine for which local cached access is significantly faster than general access.
At any time a thread has an associated cluster id (an INT), its locus of control. Until modified explicitly, the locus of thread remains the same throughout the thread's execution. When execution begins, the main routine (See main) is at cluster zero. The locus of control of a child thread is the same as the locus of its parent at the time of the fork.
Example 18-1. Example:
start_work @ least_loaded; |
expression ==>
expression @ expression |
fork_statement ==>
fork @ expression ; statement_list end |
parloop_statement ==>
parloop statement_list do @ expression ; statement_list end |
The locus of a thread may be explicitly moved for the duration of the evaluation of a method call. An expression following the '@' must evaluate to an INT, which specifies the cluster id of the locus of control the thread will be at while it evaluates the preceding method. Subexpressions of the left side are evaluated at the current locus of execution and are not relocated. It is a fatal error for a cluster id to be less than zero or greater than or equal to clusters (see See clusters). The '@' operator has lower precedence than any other operator (see See Strongest). When iterator calls are on the left side, each iterator evaluation may be placed differently on successive iterations.
NOTE: Since subexpressions are evaluated locally, the behavior that results from mathematical expressions might be somewhat unexpected. 'a:INT := b+c*d@4' is first transformed to 'b.plus(c.times(d))@4'. The subexpression 'c*d' is evaluated locally, while the expression 'b.plus(..)' is evaluated at cluster 4.
NOTE: The '@' notation may also be used to explicitly place forked body threads of fork and parloop statements. Although for these constructs the location expression may appear to be within the body, the location expression is executed before threads are forked and is not part of the body.