Emergent Cascading Distributed Termination - Graceful shutdown for libfbp

Lets stop monkeying around with termination in FBP 

TL;DR Herein proposed Emergent Cascading Distributed Termination (ECDT) whereby the libfbp component, viewed as an isolated push down automaton(PDA)[1], either:

• Reaches its own internal accept/final state and, as part of removing itself from the execution model's purview,  closes all its connection(s).

or

• Reacts to the closed exception(s) thrown by its connections(s) and reaches its own alternative, or only in some cases, final state and, as part of removing itself from the execution model's purview,  closes all its remaining connection(s).

and so on.

Thereby gracefully, and yet unknowingly, cascading the closed connections through the program graph ensemble of components allowing each to reach their final state and spread the cascade.

In order to retain the fungibility and black-box isolation requirements of FBP a component's terminating behaviour must be both dependency inverted, from an OOP perspective, and non-cooperative from a CSP theory perspective. With these immutable axioms in hand how then might libfbp not only terminate but do so gracefully?

RaspberryPi Server (Part 2): Security

Getting your head into RaspberryPi security.

TL;DR Having previously setup the RPi as a headless device logging in over ssh here the default password was changed. However, if the RPi is to function as a server then adding a new superuser, deleting the default pi user, enabling passwordless login using ssh keys, disabling password login, restricting incoming connections to port 22 only, banning IPs that fail repeatedly and setting up a restart watchdog timer will go some way to hardening the diminutive server.

UPDATE: "macOS keeps asking my ssh passphrase since I updated to Sierra" *sigh* do this:

 ssh-add -K

This stores passphrases in your keychain.

RaspberryPi Server (Part 1): Headless log in OS X

Getting all carried away with headless RaspberryPi login

TL;DR The Raspbian Raspberry Pi optimized Debian Linux image runs the ssh server by default at boot up. Hook up the Raspberry Pi to the router with a network cable, boot into a Raspbian image, find the RPi on the network and ssh into it from a terminal emulator using default user name (pi) and default password (raspberry).

Coin sized Linux WiFi Computer! My tiny SoC VoCore computer arrived today :)

The replacement for my PDP 8 has arrived.

TL;DR VoCore is an open hardware runs OpenWrt. It has WIFI, USB, UART, 20+ GPIOs but size is only one inch. I was one of many that helped fund this INDIEGOGO project way past its $6000 to its eventual $116,237! Check out their VoCore website.

Are you wondering where libfbp development has gone?

Don't worry I've just been transitioning jobs and I've got a couple of weeks off in December to pick things up again, hope I can remember what I was doing!

Any way heres some cool VoCore stuff...

Here is the little fella mounted on its dock J45, USB, microSD and power inlet.

So far I have only managed to SSH into it over wifi but here is a YouTube video of testing the GPIOs

Buliding Blocks: Experimental proof for fast lock-free connections - Also plotly is cool!

Simplicity is the ultimate sophistication.

TL;DR  An experiment to show that a lock-free queue designed to service only a single producer and single consumer can complete 1B write-read transactions in less than a quarter (27%) of the time that a multiple producer and multiple consumer lock based queue will take. Further, replacing the modulus function with a bit mask leads to further performance gains (24%) and then using the different memory models appropriately results in yet more performance gains (18%), and very cool graphs can be drawn using plotly!

C++11 Variadic template factory member function fun! Building a FBP directed graph class.

photopin cc

Better by variadic design?

TL;DR The libfbp library needs a directed graph container for the ensemble of communicating components that makes FBP programming as easy and error free as possible. Achieving these goals by giving the directed graph class the responsibilities for creation, storage, lifetime and execution of its components and connections poses the challenge of how to implement generic factory methods that allow the creation of a zoo of unknowable components and connections?  C++11/14 variadic template metaprogramming to the rescue!

A simplified libfbp component and a general purpose work-stealing, back-off threadpool to get things going.

photopin cc

Sucked into a general purpose threadpool!

TL;DR To paraphrase Thoreau "Decouple, decouple, decouple!" the clumsy component that needed to take a dequeuer is simplified to a virtual interface PPM API facilitating generalisation for PXMs. There's also a threadpool PXM so that FBP can run out of the box.

As previously stated 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. 

In an effort to achieve this goal the original component here was overly complex and took on too much of the scheduling burden the simplified component presents a single virtual operator()() member function that returns a component*. The API contract is simple, the returned component* points to the next component to be executed and a returned value of null_ptr removes the component from the execution pipeline.

Template Metaprogramming is cool! Using C++11 template overloading to make sense of queue behaviour.

photopin cc

Metaprogramming putting meat on the bones.

TL;DR Using an enumerated type as a behaviour selector at compile time by using template overloading[1] to select either total or partial queue access[2] behaviour whilst maintaining the same queue ADT interface 

The libfbp design goal is for a uniform queue interface as per the prescribed Abstract Data Type definition here using only enqueue and dequeue access class functions instead of having separate class function method calls for either partial or total access behaviour i.e. to get rid of try_enqueue and try_dequeue.

Back from 2 weeks all inclusive Gran Canaria

Went to Gran Canaria this is the infinity pool and one of the all inclusive bars... "What time is it?" "It's Caipirinha time!"

Stuff about C++11 that I like... #2 Delegating Constructors

photopin cc

Delegating constructors is cool.

TL;DR With C++11 you can kiss goodbye to some 'init' method function shared between constructors or copying and pasting between your constructors.

#libfbp freenode IRC

photopin cc

#libfbp IRC

The Future of Programming - Bret Victor / July 30, 2013 DBX Conference

Ged Byrne clued us into this one over at the Google Flow-Based Programming group:

Here is an entertaining talk: http://worrydream.com/dbx
The presenter, Bret Victor, has a simple conceipt: it's 1973.  He looks at all the amazing ideas that were coming together and shows the obvious direction of programming.
He highlights how absurd, no tragic, it is that programming is where it is today.  
I love this line: "we can rely on the computers getting faster.  What we can't rely on is people changing the way they think."
Regards,

Ged

It's all good but for me the best bit starts at 22:05

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?

Mathematical Semantics for FBP - Graph Theory

photopin cc

In search of descriptive and inferential semantics for FBP.

TL;DR In trying to develop mathematical semantics for FBP, in order to reason about FBP programs and design experiments to test hypotheses, it is proposed that Graph Theory (GT) can describe the properties and behaviours of an FBP program. Which is nice.

The value of defining mathematically based compliance design criteria for libfbp is that such a definition could serve as a standard. Such a precise specification for any FBP implementation informs the programmer using it that they can rely on certain axiomatic behaviours and, being a modular programming paradigm, be assured of the reliable conjunction of FBP modules from widely differing sources. 

Beyond its immediate utility then, developing mathematical semantics for libfbp/FBP at an early stage will hopefully forestall problems with the quality of libfbp programs—as Brookes states[1] 

“Clearly, no program can be more reliable than the implementation of the language in which it is expressed for input to a computer.”

The benefits to FBP go beyond quality issues and extend to the potential for the formal proof of correctness for a libfbp program. Given that each libfbp component is in, and as of, itself an isolated Von-Neumann machine, then Hoare-style logics for sequential languages based on state-transformation semantics are particularly suited to the way a component functions. 

In this way the modular approach to building a FBP program provides islands of correctness communicating via connections. Subsequently, and given proof of conformity with the mathematical model, FBP developers have powerful mathematical tools at their disposal to formally prove correctness. 

The question then arises as to what mathematical semantics are most appropriate for describing libfbp program structure or rather its form?

A CSP approach to FBP inter-component communication

photopin cc

Any portal in a storm!

TL;DR Sometimes maligned, C++ multiple inheritance allows an object to be 2 things at once—such as both an input port and an output port. In this way any would-be-component class that multiply descends from both fbp::input and fbp::output port classes has the is-a-relationship that enables it to be connected to any other so descended component. Neat huh?

It is axiomatic in Hoare's CSP theory[1][2][3] that the internal states of a Component are invisible to its environment and communication between processes can only take place at one of two unidirectional input and output channels. Most common variants[4] of CSP approach the two channel restriction problem by describing communication at multiple named unidirectional channels such that each CSP event m.t consists of two  parts: m the channel name and t the message content. Thus for a process that engages in event t via channel m and then behaves as process P is denoted:

m.t -> m.P

In order for libfbp to be CSP compliant then, the only communication that an fbp::component can engage in is via its named input and output ports. Assuming it is possible to build any functional FBP program using libfbp  then there is no reason that CSP compliance should be sacrificed, and with it the opportunity to use process calculus to prove program correctness. With this goal of CSP compliance in mind, what then is the best way to implement port only based communication?

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 Information Packets

What exactly are we delivering here?

TL;DR Don't look now the CSP event is the FBP IP, the FBP IP is the std::unique_ptr.

The real world has put a significant crimp on my programming of late but I have had plenty of time to think about things, so this post is rather theory heavy and code light.

The axiomatic processes of CSP Theory have been implemented as FBP Components here, here and here; but what of the FBP Information Packet (IP) - does it have a CSP equivalent?

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...

Part (2/2): Active Objects for Asynchronous Logging.

Contra-auguste Active Object

TL;DR It's just an slightly better (imho) implementation of Sutter's Dr. Dobbs 2010 articles [1][2]

As per Lavender & Schmidt's article[3] Sutter's implementation is a further refinement of the integrated scheduler variant of their original pattern removing, as it does, altogether the proxy and scheduler relying on direct message passing between client and scheduler. 

Indeed Sutter's scheduler (his Active class) contains the message queue as a private composition -which is too much integration. Too much because it forces the client to be aware of the scheduler which as an unnecessary, and avoidable, level of dependancy that binds the scheduler to the client.

The client need only be aware of the tail of the activation queue and, hence, the has-a-relationship with the message queue can be broken out of the scheduler for a more naturally component orientated approach that facilitates scheduler fungibility. Further, the scheduler need only be aware of the head of the activation queue.

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

Simplification of logging services.

As Thoreau said: "Simplify, simplify, simplify..."

The trouble with writing something in an hour or two that works is that you then have find your subconscious mind is chewing it over all the time that you're working on something else.

So it is whilst working on message_queue I couldn't resist fiddling with the logging services:

• the io namespace is gone
• serializor_policy is gone
• only the null_serializor remains renamed null_log
• ready for asycn_log
• logger now takes an output stream policy and is, consequently, more flexible
• works directly with any ostream decendent
• logger template overloads operator() 
• logger doesn't need a stringstream any longer 
• I've left the stamps alone, for now... 

TL;DR github.com/ifknot/libfbp

How it is... (2)

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

When it's time to end the relationship.

So here is the code for the single lock general purpose message queue as the obviously correct base queue type, but with one important addition...

The ability to close() the message queue.

But why?

TL;DR github.com/ifknot/libfbp

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

"The English can form a queue of 1"

Flow-Based Programming (FBP) [1], Communicating Sequential Processes (CSP) [2] and Active Objects (AO) [3] rely on message passing between otherwise environmentally opaque conccurent components. 

There are lots of ways of providing this communication[4], be that synchronous or asynchronous, but one of the most frequently used is that of a message queue.

The principle reference for my development of the concurrent queues is the, totally excellent, The Art of Multiprocessor Programming (Herlihy & Shavit 2008)

Part (1/2): Active Objects for Asynchronous Logging.

Asynchronous physical humour 

In his 2010 Dr Dobbs article[1] Herb Sutter espouses

"Prefer Using Active Objects Instead of Naked Threads"

The laudability of this is derived from Sutter's 2009 and 2007 observations[2],[3] that

"Use Threads Correctly = Isolation + Asynchronous Messages" 

(N.B. It is fascinating to read Sutter's 2009[2] & 2007[3] similarities to Sir Tony Hoare[6] 1978 seminal work on Communicating Sequential Processes(CSP)[7] and J. Paul Morrison[8] 1970s original ideas on Flow-Based Programming(FBP)[9] but more of this later...)

TL;DR Think you can walk-the-walk? You don't know Jack about thread programming if you haven't read [3], [2] & [1]

Building Blocks: C++11 Smart Pointers for the Logger Services and C++11 alias idioms

You can tell the logging services software was knocked up quickly... I completely forgot to use C++11 smart pointers[1] as part of the expressed RAII design pattern. Consequently the destructor was busy doing the pointer deleting idioms so familiar of C++03 (even if it did use the C++11 range based for loop to do it!). The changes also utilise the C++11 approach alias creation as replacement for typedef[2].

TL;DR The logging services code uses smart pointers now, but where it makes sense and not where it would make usage verbose and obfuscated.

Back From 2 weeks Snowboarding in BC

Went to Candada with snowboarding buddies this is me (centre) about to drop some fresh lines from the top of Granite Mountain BC.

Shooting from the hip... (1)

Worried about your C++ programming style and contemporary idioms? Not sure which patterns are in and which are on their way out? Concerned about software craftsmanship? Thinking of attending a coding dojo? Dithering about being an incrementalist or a completionist?

TL;DR Herb Sutter(2011) Elements of Modern C++ Style

I am, at best, an average programmer - I know this because I have been exposed to great programmers and do you know what? They're always humble and they're always learning.

However, that doesn't stop me from being mouthy and opinionated.

So, in my mind there are 2 kinds of C++ programmers:

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

The Lumber has arrived!

Freshly hewn but unfinished pile of Code Lumber is below, ideal for building your debuggin' & audtin' & tree-house solutions.

The latest versions of the code and doxygen docs are all over at the libfbp git repository github.com/ifknot/libfbp

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

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

"Logging is a critical technique for troubleshooting and maintaining software systems."[1]

I would also add that logging is a critical technique for recording a variety of metrics when conducting software analysis and experimentation.

Therefore, I need a thread-safe, asynchronous and fast data serializing framework-not only in order to develop libfbp but also to experiment with it.

There are some great libraries out there already[2] but where's the fun and learning in that?