|
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 |
Send mail to
info@stressflow.com with questions or
comments.
|