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?

CSP semantics and its traditional notation adapted for FBP were introduced here with a bit more exposure here wherein the notion of the event was casually introduced. 

As introduced in Sir Tony Hoare's follow-up[1] to his original paper[2] an event is "something" in which a process can participate and as such represents the communications or interactions that an FBP component can engage with, or in other words its behaviour. 

In this way an event triggers a transition in the behaviour of a FBP Component but is there an element of the FBP narrative description that maps, in an intellectually satisfying fashion, to the event of CSP Theory? If so is there an efficient implementation applicable to libfbp?

As per CSP Theory, axiomatically then, events are indivisible and instantaneous and can be communicated - which in popular variant(s) of the original CSP can be via named channels. The class of events that process can engage in is described symbolically in lower case.

Intuitively then the FBP Information Packet presents as the equivalent concept that maps to the CSP event. Being the communicated constituent that triggers behaviour or actions. But whilst an IP is communicated by named channels (FBP Connections) is it instantaneous and is it able to enforce a class or type of event?

A (logically) instantaneous IP

Morrison[3] approaches this ideal with the concept of an FBP Component ‘owning’ an IP or rather owning a ‘handle’ to its physical storage and that, importantly; an IP can only be accessed by its owner for the duration of that ownership. 

In Morrison’s model it is the ownership of IPs that is transferred between Components and when the number of interested owners reaches zero the finite lifetime of an IP is up. At this stage the usual strategy of “garbage collection” by the system does not automatically destroy the IP but rather it must either be explicitly destroyed by a final owning process or serialized to storage.

With the software engineering of IPs comes the first opportunity to make decisions about implementation. As described above Morrison is a proponent of what can be seen as a durability model for the IP, one where a program must deliberately destroy its IPs.

As an alternative approach libfbp adopts the antithesis of IP durability in order to meet the CSP requirement of an instantaneous event/IP. This is a deliberately more fragile model designed to meet the desired CSP compliance, whereby the information packet's existence must be deliberately maintained at each step in its life cycle otherwise its physical manifestation in memory is automatically deleted once the IP handle leaves the local scope of the transition that it has triggered in the Component. 

To borrow Morrison’s memo metaphor [3], that was used an argument for IP durability, libfbp CSP compliance requires that the memo only exists at the point at which it is sent, its creation, and the point at which it is received, its destruction. Whilst it may be copied on receipt the data is then an internal and invisible state of the Component and only becomes externally visible to environment as an IP if it is sent again to another Component.

This behaviour can be effected by using the C++11 std::unique_ptr [4][5]. The first benefit from using a unique pointer is automatic destruction of the contained object when the pointer goes out of scope. This extreme form of garbage collection stands out in code hygiene freeing the programmer from having to track every possible exit point from a routine to make sure the object is freed properly — it is done automatically. More importantly, it will be destroyed if the Component exits via an exception.

Treating the data resource in this way is termed resource acquisition is initialisation (RAII) [6] and prevents resource leakage and whilst CSP compliance is not dependent on this behaviour not only is it desirable from the point of view of automatic resource management, it is vital for the effective implementation of an exception-safe libfbp.

A type safe IP

What then should an IP handle point to? Should an IP point to anything or any kind of data such as a C++ void pointer might? Or perhaps be a reference to only one kind of data such as a C++ string type into which all other types of data are converted as per Morrison?

Neither is appropriate for a CSP compliant libfbp where at the point of event communication although the content of a message t is not—nor needs to be—known the kind of data that t is or its type T may be known.

In the FBP model an IP is data and data can be of a certain kind or class of which there can be none, one or many examples of that kind in existence, in this way data is of particular data-type or simply and commonly expressed as just type.

In the variant of CSP adopted here communication commands reference channels instead of other processes. Thus each event c.t consists of two parts, where c is the name of a channel along which the communication of a message of type t takes place.

With the definition of type comes the concept of type-safety that ensures that only operations appropriate to that data-type are permitted to take place. C++ is a strongly typed language and offers data representation by type not restricted to in-built types but also user defined types and offers, despite some annoying inconsistencies, system level type safety.

An IP, which enforces the same type as the data to which it refers, is not only CSP compliant but prevents erroneous or undesirable program behaviour caused by discrepancy between differing data-types. Such discrepancies can be detected at compile time as well as runtime and help the libfbp programmer to avoid constructing an incorrect FBP program—a highly desirable correctness feature.

The aim being to twofold:

1. To maximize the static type checking that takes place when the program is being compiled from its C++ source code into a binary executable—such that a type unsafe libfbp program is brittle and will not compile but rather halt with an error.
2. To provide dynamic type checking when the libfbp program is executing that invokes an exception handling response during execution, which by virtue of RAII permits the robust handling of such runtime errors.

It is proposed that this compile-time brittle, run-time robust approach to ensuring the correct handling of the correct data-types offers improved correctness and safety over any alternative approach to FBP implementation that is type ambiguous or type ambivalent.

In C++ implementation terms then, the desired instantaneous, RIAA, one-to-one relationship between IP & resource and type safety requirements can be achieved by using the std::unique_ptr language feature from the C++11 standard library.

If you got this far kudos and here is the code:

Problem then is, how on earth can a component maintain a generic collection of connections carrying differing type specific IPs?

What a good topic for the next post...

References:

[1] A model for communicating sequential process

[2] Communicating Sequential Processes

[3] J. Paul Morrison, Flow-Based Programming, 2nd Edition: A New Approach to Application Development, CreateSpace, 2010, ISBN 1-4515-4232-1

[4] std::unique_ptr

[5] C++11 unique_ptr

[6] RAII