[Company Logo Image]    

Home Feedback Contents Search

6.2 ASM Model
6.1 Node Model 6.2 ASM Model 6.3 Lock Constructs 6.4 Shared Memory 6.5 Distr. Memory 6.6 VPP Systems 6.7 OS View 

Back Home Up Next

6.2 Assembly Instruction Model

FIG. 32: Assembly instruction model of a task call in stress-flow

 FIG. 32 shows the view of stress-flow from the standpoint of assembly level instructions running on a particular processor. Such single task always has to be associated with some lock and the pair of them constitutes what was called in the previous sections of description the “stress-flow atom.” Such task has to release that associated lock somewhere inside the task’s sequence of instructions. This is shown as the “RELAX” signal. A task has to be able to initiate new tasks (which are also pairs of lock + sequence of instructions). This requires two signals – “RESERVE” a new task’s lock and “SCHEDULE” that task. The functioning of the “RESERVE” signal means reserving the lock if it is available or suspending the current task until the lock becomes available and reserved. The entire mechanism is an essential part of the lock mechanism and cannot reside anywhere else, no matter how the lock mechanism is implemented on particular platform. Therefore, from the standpoint of the current task – the “RESERVE” instruction is a one step command that always succeeds – even if that results in some delay. Command “SCHEDULE” a task gets executed after “RESERVE” instructions for this and possibly some other related new tasks have already been executed/reserved. These three signals or instructions are all that is required as outside interface regardless of specifics of target hardware. They can be implemented through many electronic or software means, but the idea is that this simple interface is all that should be needed for inter-process communication and synchronization.

The lock constructs utilized by stress-flow have several variations; all of them however use the same above described three-step interface mechanism, resulting in slightly different actions performed by the locks being used. Out of all possible uses, several cases have been identified where certain variation of such scheme can make sense from the standpoint of full possible optimization and ease of use in specific cases. They are not completely necessary for proper functioning of stress-flow, but will be described in order to explain the issues better.

First such case involves using a specific lock for just small “stressed” portion work only with no relaxed part, in which case it is more efficient to run said small stressed portion from within calling task, rather than schedule it as a separate task. This exception can still be seen as following the generic interface model, because the lock construct will process the RESERVE signal exactly as before, while translating the SCHEDULE signal/command to result in subroutine call or procedure in-lining within the current task.

Second such case happens in case the called task returns a value as explained in previous sections of description. In such a case, the calling task may need to be suspended to prevent a situation where it would try to use the return value before it is available. The three step interface operating on lock built to handle this situation can still do the trick in every case. RESERVE command works as before. RELAX does not release the lock but internally marks it as “Ready for Release” while SCHEDULE schedules the new task as before but also suspends the caller until the lock releases it through the “Ready for Release” internal command generated by the modified RELAX signal. When this happens, the caller gets restored and can now safely access the return value. This scheme works fine and is perfectly optimal except for situations where two or more new tasks of stress-flow(stress-flow atoms) are called from the same expression. Suppose get_a and get_b are both stress flow atoms returning integer values. Expression get_a()+get_b() will be translated like this:

          RESERVE ( get_a, get_b );  // As always in such a case, all

                                // needed locks reserved or none at all 

     SCHEDULE get_a;            // Suspended until RELAX get_a       

     SCHEDULE get_b;            // Suspended until RELAX get_b    

     < add get_a and get_b return values >                 

This code works fine – but it isn’t completely optimal since SCHEDULE get_a will suspend the calling task until the return value is available, which means SCHEDULE get_b will not be executed till then – which could result in completely unnecessary delays in some cases. For these reasons, for the sake of optimization, the interface can be expanded to include one more instruction for cases where the called task returns a value – shown as WAIT RELAX command on FIG. 32. In such a case, SCHEDULE works as it did with no-return value tasks (stress-flow atoms) while the WAIT RELAX suspends the calling task until RELAX instruction restores it, which allows running both get_a and get_b in parallel. The compilation of such a case will now look like this:

      RESERVE ( get_a, get_b ); // As always in such a case, all

                                // needed locks reserved or none at all 

      SCHEDULE get_a;

      SCHEDULE get_b;

      WAIT RELAX get_a;         // Suspended until RELAX get_a

      WAIT RELAX get_b;         // Suspended until RELAX get_b   

            < add get_a and get_b return values >

As shown above, even though this forth interface command isn’t absolutely necessary, including it makes a good sense from standpoint of optimal performance of stress-flow.

This generic and simple low-level architecture means that the user software running to be run on different platforms is the same, and the only things that are specific are the user invisible internals of lock construct and task receiving and sending interfaces. This also means that different processing platforms could be connected together as one system performing the same large job without user having to write custom software for each of them.  

FIG. 32A: Assembly instruction model of an “ordered” task call

Implementing the “ordered” stress-flow atoms requires only slight modification to the same scheme and, in practice, can be accomplished with the same lock constructs and without any modifications to the Task Sending and Task Receiving interfaces. The lock interfacing signals/commands and sequence of their usage is shown on FIG. 32A. At the beginning of the whole sequence of instructions, the PRE-RESERVE a task command has to be issued. The best way is for the compiler to insert such commands automatically for every “ordered” stress atom called out of a task. The PRE-RESERVE command simply establishes a place in line/queue of the lock for the task called further down in the sequence of instructions. If the lock has enough tasks lined up for the PRE-RESERVED place in the queue not to make it to the front of the queue before the DO-RESERVE command is issued, the DO-RESERVE simply changes the PRE-RESERVED place in queue into regular reserved place and suspends the caller just as if the RESERVE command was called instead of the PRE-RESERVE and DO-RESERVE pair. If the PRE-RESERVED place makes it to the front of the queue, the lock will be waiting until the corresponding DO-RESERVE command is issued, not allowing any tasks RESERVED or PRE-RESERVED later within the lock to execute. The SCHEDULE instruction and optional WAIT RELAX instruction work exactly the same way as with regular (non-ordered) calls. The remaining UN-RESERVE command is inserted automatically by the compiler at the end of the sequence of instructions or earlier to deal with the situation a task was PRE-RESERVED but never called due to its calling sequence being bypassed by some conditional statement. Simplest way to implement this is by always inserting the UN-RESERVE commands for all ordered calls and have them remove PRE-RESERVED places that have not been utilized yet. Another way, demanding a little more sophistication from the compiler, can insert UN-RESERVE instructions as a result of conditional statements bypassing PRE-RESERVED “ordered” call.

Back Home Up Next
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