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

Therefore, with a leap of operational intuition, it seems reasonable to postulate that the FBP paradigm is an implementation pattern for the theory of CSP (or rather its more flexible variants with named channels). The counter argument that CSP is hand-shake synchronous whereas FBP (after Morrison) is fundamentally asynchronous, has been addressed and resolved by providing an infinite buffer to the communication channel[2].

As with all MPM approaches to concurrency, in using the FBP approach there is a vulnerability to deadlock[3]. This failure of a process to progress is expressed in CSP as the STOP or broken process that refuses to engage in any events and denotes termination in an undesirable state - which is generally one of deadlock.

i.e. in the context of FBP a STOP component is one that is caught in deadlock and consequently:

• is never ready
• does nothing
• never terminates

Deadlock, by definition 'never terminates' but this last one is problematic it would be very useful to be able to recognise when a component is making no progress, but if a libfbp component is stuck in deadlock how will it know?

The issue of deadlock awareness, can be addressed by providing the connection queue with a timed condition wait expiry exception that is thrown whenever the queue is either full or empty for 'too long' (however that may be defined) that the component models as STOP behaviour.

Thus the first thing to add to libfbp is the base fbp_exception and then derive fbp_deadlock_exception thusly:

With which the STOP component can be described...

Hence, the first concrete derived child class from the component base class is the stop class, being deadlocked is unable to engage in any information packets and, being broken, simply throws the fbp_deadlock_exception and stops.

Thus from any child class of stop if deadlock behaviour is detected all the component needs to do is drop back to its broken state and behave accordingly:

Using CSP semantics to describe this libfbp implemented FBP behaviour then when any component engages in a deadlock event it behaves as a STOP component denoted thus:

(deadlock -> STOP)

Having introduced the -> operator and generalising this CSP notation applied to FBP for any occurrence, termed an event,  at the left of the arrow operator a resulting component behaviour at the right ensues:

(e -> C)

Read: Some described FBP Component engages in event e, then behaves as described by C.

Well, that's unsuccessful termination covered but what about successful termination?

What a good topic for another blog entry...

References:

[1] Communicating Sequential Processes

[2] Communicating Parallel Processes

[3] Deadlock