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!

A CSP approach to FBP Components: #2 SKIP success component.

Successful termination.

TL;DR  The next primitive CSP process to emulate in libfbp is SKIP for successful termination.

Given that the theory of Communicating Sequential Processes (CSP) is not a programming language but rather a mathematical notation for process algebra, nevertheless, there are a number of concurrent programming languages based on CSP; for example occam and Ada .

A CSP approach to FBP Components: #1 STOP the broken component.

Handling the broken component.

TL;DR FBP originates from the unashamedly pragmatic narrative tradition of software development and, consequently, lacks any mathematical semantics. The Theory of CSP is proposed not only as mathematical semantics for FBP but also a basis for its design and implementation. (Which I discuss at length in my Masters Thesis.)

As previously discussed here, it is clear that FBP falls into the Message Passing Model (MPM) of concurrency models. Further, message passing between isolated processes is a rudimentary description of not only FBP but also of Sir Tony Hoare's Communicating Sequential Processes (CSP)[1].

libfbp component interface

One Interface to rule them all, One Interface to find them,
One Interface to bring them all and in the Scheduler bind them
In the Land of Execution Models where the Programs lie.

TL;DR A PXM API for the libfbp PPM Components whereby; the underlying execution service can view each Component as an enqueuer of message requests[1] composed of C++11 function<void()> types behaving as functors[2]. 

The primary strategic goal here is that the libfbp implementation of Flow-Based Programming (FBP) as a Parallel Programming Model (PPM), though the FBP paradigm is a lot more more than simply a PPM, should be agnostic to its underlying Program eXecution Model (PXM) but must, never-the-less, provide an Application Programming Interface (API) that remains versatile in its implementation. 

Lovin' the TinyDuino mini Atmel 328 Arduino Board

My TinyDuino - what a perfect distraction!

• Atmel ATmega328P Microcontroller
• 32KB Flash, 2KB RAM, 1KB EEPROM
• 1.2mA (typical) @ 3V, 4MHz
• Default Clock speed: 8MHz
• 2.7V – 5.5V operating voltage (Arduino mode)
• 1.8V – 5.5V operating voltage (with custom fw)
• 20 I/Os (14 Digital, 6 Analog / Digital I/O) – All the signals on the Arduino Shield connectors are supported!
• Arduino Bootloader preprogrammed (uses approx 0.5 KBytes of Flash Memory)

This build is rocking the TinyShield USB & ICP programming shield, TinyShield microSD and TinyShield 16 Edge LEDs.

Stuff about C++11 that I like... #1 Inherited Constructors

Inherited constructors make life easy.

Depending on your mood the (counter)intuitive scope behaviour of class members such that ordinary scope rules apply to class members. In particular, a member of a base class is not in the same scope as a member of a derived class.[1]

Static variables in template class results in smart enqueuer-dequeuer pattern.

Decorator pattern[1] tricks to reduce queue dependency

TL;DR this one simple trick for static member initialization in a class template[2].

The original rather dumb enqueuer and dequeuer used the shared_queue class to track their counts and close the underlying queue accordingly. Giving them each their own static count makes the shared_queue wrapper redundant and usage more intuitive, but how to initialise the static variable was a brief head scratcher...