[Company Logo Image]    

Home Feedback Contents Search

4.8 Connector
4.1 Structure 4.2 Compiling 4.3 Example 4.4 Socket 4.5 OOP 4.6 Competing 4.7 Optimization 4.8 Connector 4.9 Merging 4.10 Emulation 4.11 Ordered Calls 4.12 Last-Only 4.13 Group Inputs 4.14 Complex Sys. 4.15 Prior Art... 4.16 Redundant SW 4.17 Visual SW 

Back Home Up Next

4.8 Advanced Connecting of Stress-Flow Atoms

 In all previous examples if a stress-flow atom wanted to invoke one or more stress-flow atoms, it had to do it explicitly by calling each of them by name. There are instances, however, when it is desirable for a stress-flow atom to be designed in a way that would allow it to call a dynamically created list of atoms. Another way to look at it is as a dynamically created call-me list to which other atoms would add themselves. This concept takes us even further toward being able to replicate data-flow concepts.

For example, suppose we have a timer that “ticks” every couple of milliseconds and we want to be able to have a list of stress-flow atoms to be activated with every tick. Another example would be an event such as a key being pressed on the keyboard or mouse being moved that need to be processed by one or more separate processes. Such a construct can be roughly created in an object-oriented language on top of stress-flow as a “standard-library” type addition without need of special keywords. This is however a very important feature of stress-flow – one that makes it far more usable, justifying making the feature as part of basic syntax of a language implementing stress-flow. Due to characteristics of this construct, it is referred to as “connector.” To create a connector, the user would simply type the following declaration:

connector <name>(<list of parameters>) ;

 The command to “connect” an actual stress-flow atom to a connector could look  like this:

<connector name>.connect(<stress-flow atom name>);

 A special operator made for that purpose will make matters more clear:

<connector name> => <stress flow atom name);

 

struct mouse_driver

{  connector mouse_moved(int x, int y);

   detach move(int x,int y)

   {  return;

      mouse_moved(x,y);

   };

} mouse;

//----------------------------------------------------

struct window

{  detach mouse_move(int x,int y)

   {   //code for processing mouse messages

   };

   window ()

   {   mouse.mouse_moved=>mouse_move// connect

   };

}; 

FIG. 9: An example of using connector construct

An example of connector construct application is shown on FIG. 9.

To an invoking routine, the connector and its invocation is exactly the same process as calling a single stress flow atom: reserving its lock, scheduling its contents, being suspended while waiting for the lock being marked and releasing the lock. However, each of these steps is internally translated into consecutive loops on all elements stored in the connector. If parameters were passed, a copy of actual parameters would have to be prepared for each connector element.

 

struct value_cache

some_type      value;

   connector      changed();

   detach void    change(parm_type parm)

   {  value = type;

      changed();

      return;

   };

};

FIG. 10: An example of connector construct used to synchronize one producer and many consumers of data

At first the connector concept does not seem particularly earthshaking. It is however an essential tool for creating truly object-oriented programs where all desired synchronization and parallelism is integral part of object definition which was the main objective of stress-flow. The usefulness comes from the fact that the connector is built from a number of assigned stress-flow atoms and thus inherits and bounds all their stressed/relaxed features and resulting synchronization together. Suppose we need to deal with some piece of data that is constantly being changed. The piece of data is so large that it does not make any sense to store it more than once. However, we need to be able to let a number of unspecified objects to be able to process the data before we allow this data to change again. A stress-flow solution of this problem is shown on FIG. 10. To change the cached value, outside process calls stress-flow atom “change” with a parameter defining the way the cached value is being changed. This changes the value and calls the “changed” connector which causes all objects interested in being scheduled to do their job. A large number of new atoms/processes can now automatically come to life as a result of one statement. Due to the fact that that all this happens in the stressed portion of the “change” atom, the process calling “change” is now being stalled and prevented from changing the value until all atoms connected to the connector properly process/copy everything they need from the value. Without knowing absolutely anything about neither the process causing changes in “value” nor multiple processes running in parallel that need to process the changed values, our simple, and very concise definition defined a very advanced interaction between them.

The most commonly used connector repeats the actions of a number of stress flow atoms compounded into single expression, meaning that invoking the connector would stall until locks of all member atoms could be reserved together. A modified connector that would ignore currently unavailable atoms and only reserve and run the ones currently available could also be useful in many circumstances.

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