Shattered Control Flow

     

The statements described earlier in this section have all provided a single thread of control in that a single statement executes at a time. ZPL also has the notion of shattered control flow: When a parallel expression is used in the conditional of a compound statement, the control flow is said to shatter and each index value has its own thread of control. The semantics of shattered control flow are the same as that of an anonymous sequential procedure that has been promoted (See Section 6.2.2).

Certain restrictions are placed on shattered control flow to guarantee predictable and meaningful results.

• The basic restriction is easily understood: Shattered control flow creates multiple threads of execution, one per array index; to ensure that all threads can execute independently, the code for each thread may only refer to parallel array elements that have the same index as the thread. There are several implications of this restriction:
  • The use of @, wrap, reflect, floods, reductions, and scans is illegal. In addition, the region that is applied to statements of shattered control flow cannot be changed within the shattered control flow.
  • Sequential variables cannot be modified inside shattered control flow. Since sequential values are available in all threads, this would violate the independence of the threads.
  • Only parallel variables of the same rank as the shattered control flow may be referenced. For example, if the shattered control flow were two dimensional, it would be illegal to reference 3D parallel expressions. Furthermore, parallel procedure invocation, including file I/O, is illegal since each invocation would refer to indices from other threads.
• To guarantee that a single thread of control is possible upon exit, return statements cannot appear inside of shattered control flow.

• Masks vs. Shattered Control Flow.