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?

The first pass at deconstructing the port concept results in a collection of one or more named, iteratable connection access points at which IPs can either be received into the component or sent out from it. However, the fbp::portal class is a result of a second deconstruction that recognises that a collection of fbp::connectable pointers indexed by a port name is a more fundamental base class with no need to provide IP send and receive behaviour.

Figure 1. portal container class diagram

Code listing 1. portal class

This separation allows the fbp::portal class to act as base class to fbp::input and fbp::output classes that do provide the necessary communication functionality by using template class functions for type specific send and receive behaviour. 

Figure 2. class diagram (additions in blue) shows the portal, input and output triad.

This separation of communication functionality from the container class that holds the named ports is fundamental to the way libfbp is used and its flexibility.

As such, in order to establish a connection between libfbp component(s) it is only necessary to provide a component object that descends from the fbp::input or fbp::output or, by multiple inheritance, both the fbp::input and fbp::output classes. Then by virtue of the is-a-relationship connection then becomes straightforward task for any kind of libfbp component:

connect(fbp::output* out, fbp::input* in);

The connect function can take as its arguments any two components that are descended from fbp::input or fbp::output, or—by virtue of multiple inheritance—both, and the compiler will correctly cast the first component to an fbp::input class and the second component to an fbp::output class.

Code listing 2. input class


Code listing 3. output class

In this way the component communication services are separated into a base container class that holds one end of a connection indexed by a port name and two separate communication classes that provided template functions for sending and receiving IPs and it is within these member functions that the fbp::connectable is cast up to its appropriate typed fbp::connection<T> as shown at lines 14 in code listings 2 & 3.

Usage is intuitive from within a component thusly:

out_ports.send<int>(ip_type(new int{13}), "m");

and...

int t = *in_ports.receive<int>("m");

This is a simple but powerful approach that not only provides any number of compiler constructed type safe send and receive member functions but with template specialisation permits type specific behaviour, should that be desired. Such a template metaprogramming approach, available in the C++ 11 programming language, results in a pluripotent FBP implementation.

For example, consider the relative ease with which can be defined a source component that descends from the fbp::output class that, by its very nature, only need provide send behaviour:

class Source: public output {  

 ...  

}

  

Then consider a sink component type that only needs receive behaviour:

class Sink: public input {    

 ...    

}    

Finally consider a filter component type that provides both send and receive behaviour:

class Filter: public input, public output {  

 ...  

}  

Then connecting all 3 is trivial and intuitive:

Source* a = new Source();  

Filter* b = new Filter();  

Sink*   c = new Sink();  

connect(a, b);  

connect(b, c);  

Coalescing the design class diagrams described so far into an overarching class hierarchy diagram elucidates how the classes described so far interact to build a first simple source-filter-sink pipeline that processes information packets:

Figure 3. libfbp communication hierarchy

With the basics of a CSP compliant libfbp implementation of FBP in place one can now start to construct FBP programs from the connections between components.

Hmmm but...

Given that the "programming" in FBP is more about the connections made between components, rather than the components themselves, what mathematical semantics might be appropriate for trying to capture and reason about those connections?

In other words, how can the concepts graphed out in the FBP connection diagram best be expressed mathematically?

Needless to say I've been thinking about this one lately and thought it might make a good topic for the next post.

References:

[1] Charles Antony Richard Hoare, "Communicating sequential processes," Communications of the ACM, vol. 21, no. 8, pp. 666-677, 1978.

[2] Charles Anthony Ricahrd Hoare, Communicating sequential processess., 2004.

[3] Leslie Lamport and Fred Schneider, "The "Hoare Logic" of CSP, and All That," ACM Transactions on Programming Languages and Systems, vol. 6, no. 2, pp. 281-296, April 1984.

[4] S.D. Brookes, C.A.R. Hoare, and A.W. Roscoe, "A Theory of Communicating Sequential Processes," Journal of the Associationfor Computing Machinery, vol. 31, no. 3, pp. 560-599, Jul 1984.