A CSP approach to FBP Components: #3 RUN the livelock component #4 CHAOS the unpredictable component

Just because you're doing something doesn't mean everything is going well!

TL;DR The CSP process RUN represents livelock[1] and the entirely unpredictable mix of livelock and/or deadlock[2] is represented by the CHAOS process. Despite the difficulty in detecting these 2 worse case scenarios they are embodied as libfbp components.

The distributed deadlocked component that is failing to progress can be detected[2] by limiting the amount of time that a component will tolerate failing to progress. A much harder situation detect is one of livelock where a component will engage in any Information Package (IP) without making any meaningful progress. Harder still to detect is that chaotic component which can either engage in any IP or refuse to engage in any IP - it is in a superposition of livelock and deadlock!

Given that the 3 situations of deadlock, livelock and the chaos of both can be specified then, regardless of the difficulty or otherwise of their detection,  it is necessary to open up the libfbp exception hierarchy to include all of the CSP broken process behaviours:

libfbp exception hierarchy:

The implementation of livelock and chaos exceptions are as trivial as that of deadlock:

The important CSP processes of RUN and, in particular, CHAOS must be avoided at all costs and given that they can be present in specifications then libfbp must possess components that implement them. 

In this way having all of the fundamental CSP theoretical processes expressed as components then the resulting libfbp basic component class diagram is now complete:

Once again the run and chaos components are as trivial to implement as their matching exceptions. However, distinct from the stop component, which was subsumed with a private constructor under its befriended skip component, the run and chaos components do not subsume skip. 

Rather, it is likely that most functioning components will descend from skip, leaving run and chaos for specialisation in scenarios where their unique broken behaviours can be detected.

Having been asked the, not unreasonable, question: "How to use these classes?" Then this is the primitive test harness for theses classes using the active object scheduler from this post:

With the associated, somewhat idiosyncratic (courtesy of my errors.h file), output:

(╯°□°）╯︵ ┻━┻ This component doesn't know if it's coming or going!
/libfbp/aob/scheduler.h ᕕ( ᐛ )ᕗ 
 d(^_^d) Program ended with exit code: 1

Now, what do about FBP Connections and their CSP counterpart, named channels?

One thing is for sure though, I do not want every datatype to be converted to a string IP!

There must be a better way...

References:

[1] Livelock

[2] Deadlock detection