Reading List

The Selfish Gene
The Psychopath Test: A Journey Through the Madness Industry
Bad Science
The Feynman Lectures on Physics
The Theory of Everything: The Origin and Fate of the Universe


ifknot's favorite books »

Friday 23 May 2014

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

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.


The solution adopted for the libfbp is to have an untyped connectable base class from which the typed connection<T> class inherits its core functionality. In this way the connectable base class is passed as arguments in functions and acts as the class that is stored in collections. It is only cast to the specific typed connection<T> when the IP is communicated. 

The abstract fbp::connectable base class is the first step in a powerful type separating pair from which all concrete means of getting IPs from one black box component to the next must descend.

Figure 1 shows that the class diagram for this connection couplet is simple but hints at its potential… 

Figure 1. Connections class hierarchy

Consider a double buffered connection to avoid false sharing when communicating between components on separate cores, or a connection for communicating between components across the internet, or any variety of specialised or dynamically optimised implementations of the FBP connection concept. Each with their own unique send and receive mechanisms that are not exposed until momentarily cast up from their connectable base class at the point of a send<T> or receive<T> request by a component. 

The key, liberating, concept with the fbp::connectable class is that acts as the untyped proxy for any kind of connection and, as such, can be freely passed around as an argument until the deliberate, and hence strongly typed, casting to the fbp::connection class. The fbp::connectable class, therefore, has no IP communication behaviour. Rather the typed fbp::connection<T> presents the send and receive interface via its private pure virtual do_send and and do_receive member functions. In this way implementing Sutter’s[1] Non-Virtual Interface (NVI) idiom to provide the interface for IP communication. Leaving the actual communication mechanics to be provided by its type specific descendent(s).

Code listing 1. connectable class


Code listing 2. connection interface


Concrete connection class descendants of the connection interface must implement the do_send and do_receive virtual private member functions for example the simple fbp::buffered_connection class.

Code listing 3. buffered_connection class



In order to be CSP compliant the only communication that a FBP component can engage in is via its named input and output ports. With the classes necessary to connect components together what then is the best way to implement port only based communication? (I can feel a catch phrase coming on.)

"What a good topic for the next post..."

References:

[1] Herb Sutter, "Virtuality," C/C++ Users Journal, vol. 19, no. 9, September 2001

No comments:

Post a Comment