[Company Logo Image]    

Home Feedback Contents Search

6.6 VPP Systems
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.6 Virtual Parallel Platforms

FIG. 34B: Implementation of stress-flow on virtual parallel platforms

FIG. 34B shows implementation of the TSI and TRI concepts on “virtual parallel platforms.” The idea behind virtual parallel platforms is to use “commodity” type computers connected through network or similar such means. The characteristics influencing the design of TSI and TRI in this situation include the fact that each such system has its own local memory and can only access the memory of the other nodes through the network medium, placing substantial penalty on it. The nodes, however, are all connected with all other nodes equally well, meaning, there is no penalty associated with choice of node other than its current load (in most practical cases, but not all). As before, the processor and a lock on this drawing are greatly simplified here, shown only to explain connections of TRI and TSI. Full architecture of these parts was shown on FIGs 31 and 31A. An important part of this implementation is a “Load Table” containing frequently updated information about current processing load of all nodes. This information is critical for routing and re-routing tasks.

Ready task definitions arrive to a node through networking medium and network interface that implements proper protocol allowing sending the stress-flow task definitions over it. A task received by a node is placed in TRI’s Task FIFO. Due to peculiar characteristics of this platform, this FIFO will generally hold much more tasks at any given moment that other implementations. This has to do with the data transfer overhead. While the tasks wait in this FIFO, the “IN Data Fetching” interface copies needed data into the current node using the network interface. When the processor becomes available, it takes a task from the TRI’s FIFO and executes it. If it needs to initiate a new task, it communicates with a lock, which in turn can eventually send a new task definition to a node’s TSI. When the processor finishes the task, the TRI “OUT Data Sending” block copies result data to the proper location when this is necessary. A more sophisticated organization of TRI will allow it to check/react to  other nodes’ load situation and take waiting tasks out of its FIFO and send them away if load situation changed enough to justify doing so – for example another node ending all his tasks while there are several tasks waiting in FIFO here.

The connection between the lock and the Network Interface needs special attention here. As always, the lock needs some storage area generated at the scope where it was created or with it. This means that the lock storage in some cases here might result being located at another node. Being a critical mechanism regulating access, it has to always be accessed in its original location. This instituted no problem whatsoever in previous platforms because the operations needed are always very short and the previous platforms had access to all memory, even if at some penalty if the location was remote. Here, like anything else remote, the lock storage access needs to go through network interface. Short, special purpose network messages have to be implemented for just this task. This isn’t as bad as it sounds. The operations needed are short, requiring sending one message and in some cases waiting for one response. When waiting for the response, the node/processor can process other waiting tasks. In particular, when implementing the critical RESERVE command mechanism, we simply send proper command to the Network Interface and suspend the caller assuming that the command failed until we get a response back that says that it didn’t. Regardless if the lock was free or not, the operation here will be the same thanks to stress-atom concept features. In all cases, all complexity of lock interactions needs to be performed as part of the lock interfacing task and node, while lock storage is just a few bytes to access. This is why lock was drawn as device between running task and the TSI.

The “location” information here is specially configured to allow efficient node assignment based on amount of data that will have to be copied from node to node. The TSI looks at “location” information of all tasks sent to it, processes it together with current “Load Table” information and routes the task to one of the nodes or to the task FIFO of its own node. In virtual parallel implementations, due to the data copying overhead, directing the task to the same node is more often preferred than in other implementations. Once an outside target node is selected, the task definition is sent to the “Network Interface” where complete stress-flow task definition network message is assembled and sent. Please note that exact demarcation lines between TRI, TSI, the “Load Table” and the “Network Interface” are unimportant “academic” details of the implementation. The only demarcation lines of importance are those between the code running on the processor and what it accesses. These demarcation lines remained unchanged allowing universal portability of code written in the spirit of stress-flow.

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