[Company Logo Image]    

Home Feedback Contents Search

Concept Announcements 

Home Next

1 Introduction
2 Background
3 Goals
4 Software
5 Implementation
6 Electronics

Control-flow and dataflow represent two extremes in models of programming and in computer architectures. The methods are diametrically different with control flow essentially driving processing through explicit sequencing of commands or requests and dataflow being driven by data availability, dependency, or interactions. One problem with these approaches is that there is little in between, often requiring clear commitment to one of the models. The other is that both methods seem awkward as compared to how living organisms operate. This might at first sound like an abstract, useless philosophical posturing, but let us try imagine describing, say a day in office as a pure control-flow or data-flow type algorithm.

Pure control-flow representation of day in office would have a giant loop testing readiness conditions of different events, for example: if phone ringing then pick up the phone and talk; if document ready to be processed, process it; if someone comes to talk, talk, etc. The method is unnatural because we do not actually run our lives through loops checking for every possible event that might take place and because we are capable of doing more than one task simultaneously. Such pure control-flow model does never work in non-trivial computing applications, requiring software and hardware workarounds in order to, for example, avoid wasting computing resources on constant polling for all possible events or to be able to safely do more than one task at the same time. 

Pure dataflow representation of day in office would package all incoming data to process into some sort of input tokens. This works well with inputs that are already delivered as pre-defined packages (say documents or e-mails to process). But it does not work at all for describing procedure or protocol of someone coming over to talk or responding to events like fire alarms, lunch break, or going through procedure of making a coffee.

These were the observations leading to development of programming method presented here. Assumption that both control-flow and dataflow are fundamentally unnatural led to the conclusion that there must be a different, possibly far better way.

Objects in nature do not run polling loops or set themselves up as recipients of data-tokens from other objects. What objects in nature do instead is respond to various assortments of stimuli (stress) and in the process of responding to them generate stimuli for other objects. This is the essence of the method proposed here. Autonomous objects as building blocks of complex programming systems which on their own define all aspects of their existence including, as a fundamental component, all aspects of parallelism and required restrictions on it (synchronization).

StressFlow Concept Description

bullet1 Introduction to Stressflow
bullet2 Background Leading to StressFlow
bullet3 Goals of StressFlow
bullet4 StressFlow Software Design View
bullet4.1 Basic Structure of StressFlow Atom
bullet4.2 Methods of Compiler Implementation
bullet4.3 Basic Programming Example
bullet4.4 Construct for Interfacing with Legacy Code
bullet4.5 Object-Oriented Example
bullet4.6 Competing for Resources
bullet4.7 Optimization of Parallelism in StressFlow
bullet4.8 Advanced Connecting of StressFlow Atoms
bullet4.9 Merging StressFlow Atom Paths
bullet4.10 Emulation of Electrical Systems
bullet4.11 Ordered StressFlow Calls
bullet4.12 Last-Only StressFlow Calls
bullet4.13 Group Inputs and Default Path
bullet4.14 Complex, Dynamically Created and Modified Software Systems
bullet4.15 Comparison to Prior Art DataFlow Tools
bullet4.16 Application in Redundant Software Design
bullet4.17 Application in Visual Programming
bullet5 Implementation Issues
bullet5.1 Stack Use, Automatic Stack and Deallocation
bullet5.2 Inner Workings of Implementation
bullet5.3 Implementation in Microprocessors
bullet5.4 Application in Parallel Architectures
bullet5.5 Application in Virtual Parallel Platforms
bullet6 StressFlow Electronic Architecture View
bullet6.1 Electronic Architecture Node Model
bullet6.2 Assembly Instruction Model
bullet6.3 Lock Constructs
bullet6.4 Shared Memory Systems
bullet6.5 Distributed Memory Systems
bullet6.6 Virtual Parallel Platforms
bullet6.7 Application in Operating Systems

Home 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