4.11 Ordered Stress-Flow Calls

The atomic concept and operation principles of stress-flow atoms have made another solution possible for such problems requiring chains of operations to maintain chronological order. Suppose that at the beginning of every stress flow atom in such chain operation we would call the next atom(s) in chain and “informed” it/them to expect the data some time later. The target’s lock has the list of atoms queued up/suspended and to be awaken when it is their turn to get the lock. All what such a “reserve-a-place-for-me” call would do, is create an entry with the calling atom’s ID/pointer, but marking it to inform that this is not yet a completed call, and not suspending the caller. When the actual call is later made, all that has to be done is to “unflag” the reserved place in the queue and to suspend the caller. If it the reserved place would make it to the head of the queue before the actual call was made, the target lock would be suspended until the actual call would wake it up. The whole process is quite easy due to low level atomization of the entire solution into mini-threads.  

FIG. 15: Manually generated ordered stress flow atom

FIG. 15A: Compiler generated ordered stress flow atom

FIG. 15B: A new operator used in place of additional keyword

FIG. 15C: Manually generated ordered atom using the new operator

The reservation process could be done explicitly, by using keyword as shown in FIG. 15. This coding is most natural due to the way it has to be implemented, and actually can be implemented with a regular compiler – but it is a little cumbersome. The ordered calls themselves could be marked as such by some special keyword or operator as shown on FIG. 15A which would make the compiler automatically find all such calls and build a proper reservation list executed at the beginning of the atom. Allowing this implicit method is desired due to the way the method is most commonly used even if it puts more strain on the compiler construction. The disadvantage of this method is difficulty to call stress-flow atoms out of expressions unless some special operator was reserved instead of keyword for this purpose, for example: !!add_a as shown on FIG. 15B. The explicit, manual method is however desired in some circumstances, and when used together with the special operator, it would result in code shown on FIG. 15C. It may appear that using both manual reservation and the new operator is a little redundant, but the framework shown here is used to implement other mechanisms similar to the “ordered” scheme. In case explicit reservation method is used, the compiler could allow declaring type of the call as part of the reservation scheme instead of part of the call. In example on FIG. 15C if the reservation had format “reserve !!add(aaa_a)”, the call to “add” would not need the “!!” or “ordered” operator. Another way to declare the “ordered” stress-flow atoms would be to reserve another operator (like “ordered”) and use it as stress flow atom definition modifier. Any use of such stress flow atom would generate the proper modified “ordered” calling sequence as described here.

FIG. 16: Code from FIG. 13 using ordered stress flow atoms

Most uses of the “ordered” stress flow atoms do not need manual explicit reservation and automatic method will be used in the following examples. The special “!!” will also be used other than a new keyword as shown on FIG. 16. All stress-flow atoms calls used have been now marked as ordered and so the atom bodies can be safely moved to the relaxed section. The performance of the circuit now mimics the timeline from FIG. 14A and there is no danger of disordered data.

Proper implementation of ordered stress flow atom call must deal with the case in which the “reservation” call was made at the beginning, but the actual call never came due to some conditional construct inside the code. The implementation must then issue an “un-reserve call” at the end of the calling routine.

Internally, the compiler builds for every stress-flow atom a list of “ordered” atoms that can be called by current atom. This list will from now on be called the “order reserve list”. At the beginning of each atom, the compiler also inserts code that reserves places on local stack for the pointers/references to the queue places reserved for all order reserve list atoms. Actual call to a reserved location takes stored value, uses it to properly modify the queue and then zeroes the pointer stored on local stack. Upon reaching the end of execution of the stress flow atom, all pointers to the reserved locations are checked. If any of them is still non-zero, the “un-reserve” call is issued. What this call does relates to the “default path” processing described in separate section.

Send mail to info@stressflow.com with questions or comments.
Copyright © 2005-2010. All Rights Reserved. Patents Pending in Multiple Jurisdictions.
First published 03/29/06. Last modified: 06/25/10