Mathematical Semantics for FBP - Describing Fundamental FBP Program Types

photopin cc

A glittering treasure of mathematical semantics for FBP or fool's gold?

TL;DR Examples of using mathematical semantics for FBP by combining (named channel) Theory of CSP and Graph Theory to describe 3 fundamental FBP program graph types which can form the basis for both reasoning about experimenting with libfbp programs.

As I have argued so far here, here, here, here, here and here, my overarching proposition in searching for a useful mathematical description for Flow Based Programming is that an FBP network of black box processing components that communicate information packets via one-way connections can be modelled as a directed graph of communicating sequential processes.

But how might such a model be usefully applied to reasoning about FBP and what might a fundamental FBP program be?

In searching for fundamental classes of FBP programs is it worth trying to define programmatic identities that can be compared both within and across implementations to reason about a class of FBP programs?

Compile-Time Brittle Run-Time Robust Static Type Safe FBP Connections

photopin cc

A bit of C++ untyped-to-typed separation template magic...

TL;DR You can have your cake and eat it! With collections of non-typed connectable classes static_cast to the typed template connection<T> interface opens up a world of ways of connecting together components!

The design decision to construct libfbp as a strictly type safe implementation of FBP is primarily aimed ensuring that no operation leads to undefined behaviour. 

Unfortunately there is an implementation dichotomy between being able to create a typed first-class FBP connection object and freely pass around such connections as the arguments in generic functions that manage those connections or the collections that store them.

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!

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. 

Part (3/3): A general purpose thread-safe internally synchronized message queue.

Proxies: Who's wearing the trousers? 

TL;DR I want to be able to do this:

producer_active_object(enqueuer_proxy(concurrent_queue));
consumer_active_object(dequeuer_proxy(concurrent_queue));

Today' reference will mostly be:

The proxy pattern[1] provides restricted or modified access to hidden or protected resources. There are a few subsets of proxies:

• remote proxy
• virtual proxy
• protection proxy
• smart reference

The kind of proxy that the message_queue type needs is combination of the last 2 that offers:

• Access to the head and tail of the message queue via its various private enqueue and dequeue member functions.
• Counting the number of references to the message queue and closing it down when either there are no more interested consumer(s) or the producer(s) have finished producing. 

Okay so the design choices are to either:

1. Have a zoo of some_message_queue types each with member functions for generating their own proxies that use the extremely useful friendship C++ language feature[2]
2. Select a specific some_message_queue policy from the zoo and wrap it in a generic message_queue type which dishes out the head and tail proxies.

Well at least there is no goat in this problem so in true Monty Hall style 

"Let's see what's behind door number 2..." 

Online Collaborative UML Modelling - GenMyModel

www.genmymodel.com It's really rather good!

GenMyModel Log in from and link to your github account, it's really rather good and I'm not the only one[1]

References:

[1] stackoverflow: Tools for creating Class Diagrams

Part (2/3): I'm a Lumberjack and I'm okay.

With the software design description (SDD) contexts in hand from the previous post here and using a deconstruction of the excellent Dr. Dobbs article "A Lightweight Logger for C++" by Janiszewski (January 31, 2013)[1] as a basis for implementation then given the following observations about that article:

Pretty pictures

There are lots off online tools for drawing pretty pictures diagrams[1]

Lucidchart is free (for cut down but adequate version) and works with Google Drive I think I'll give it a whirl.








References:
[1] http://stackoverflow.com/questions/6877121/is-there-a-free-browser-based-uml-modelling-tool