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.
From a PPM perspective the FBP paradigm is message passing model (MPM) [3]. In a message passing model, parallelizable tasks exchange data through passing messages to one another. As described by Morrison[4] in FBP these communications are expressed as information packets (IP) passed asynchronously between tasks termed components via channels termed connections.
A MPM approach is a liberating one that enables:
- (Dynamic)Distributable - a component shouldn't care where it is executed and nor should it necessarily be bound there.
- Non-contentious - unlike a shared memory model FBP components do not share memory and therefore avoid memory contentions. Ideally the memory footprint of a component (granularity/grain size) of a component should fit in lowest cache level to avoid even cache contentions.
- Simplified Synchronisation - connections look after synchronisation and can be made fungible to improve programmability.
- Scalability - all of which results in the MPM and hence FBP approach being an inherently scalable one.
The problem for libfbp is how to interface a polymorphic set of components in a user opaque way with any underlying PXM?
The most general purpose way to do this is to simply provide a functor to the PXM that executes the extant component behaviour, but how to get the functor(s) to the PXM?
The chosen API approach is to view each component as an enqueuer of function<void()> types.
The component template base class requires an enqueuer type T that follows the Abstract Data Type (ADT)[5] interface and offers the non-virtual void run() interface with its underlying Private Virtual Interface idiom[6].
Each component can be viewed as a task with a start state of DEACTIVATED-which it necessarily must as constructor ordering may allow an instantiated base class on the message queue to call an partially/unfinished child class implementation. A RUNNABLE state once activated and a final accepting state of TERMINATED on completion.
The resulting abstract template base component class:
The chosen API approach is to view each component as an enqueuer of function<void()> types.
The component template base class requires an enqueuer type T that follows the Abstract Data Type (ADT)[5] interface and offers the non-virtual void run() interface with its underlying Private Virtual Interface idiom[6].
Each component can be viewed as a task with a start state of DEACTIVATED-which it necessarily must as constructor ordering may allow an instantiated base class on the message queue to call an partially/unfinished child class implementation. A RUNNABLE state once activated and a final accepting state of TERMINATED on completion.
The resulting abstract template base component class:
References:
[4] J. Paul Morrison, Flow-Based Programming, 2nd Edition: A New Approach to Application Development, CreateSpace, 2010, ISBN 1-4515-4232-1
[5] Queue (abstract data type)
[6] http://www.drdobbs.com/conversations-virtually-yours/184403760
[5] Queue (abstract data type)
[6] http://www.drdobbs.com/conversations-virtually-yours/184403760
No comments:
Post a Comment