Part (2/2): Active Objects for Asynchronous Logging.

Contra-auguste Active Object

TL;DR It's just an slightly better (imho) implementation of Sutter's Dr. Dobbs 2010 articles [1][2]

As per Lavender & Schmidt's article[3] Sutter's implementation is a further refinement of the integrated scheduler variant of their original pattern removing, as it does, altogether the proxy and scheduler relying on direct message passing between client and scheduler. 

Indeed Sutter's scheduler (his Active class) contains the message queue as a private composition -which is too much integration. Too much because it forces the client to be aware of the scheduler which as an unnecessary, and avoidable, level of dependancy that binds the scheduler to the client.

The client need only be aware of the tail of the activation queue and, hence, the has-a-relationship with the message queue can be broken out of the scheduler for a more naturally component orientated approach that facilitates scheduler fungibility. Further, the scheduler need only be aware of the head of the activation queue.

Part (3/3): A general purpose thread-safe internally synchronized message queue.

Proxies: Who's wearing the trousers? 

TL;DR I want to be able to do this:

producer_active_object(enqueuer_proxy(concurrent_queue));
consumer_active_object(dequeuer_proxy(concurrent_queue));

Today' reference will mostly be:

The proxy pattern[1] provides restricted or modified access to hidden or protected resources. There are a few subsets of proxies:

• remote proxy
• virtual proxy
• protection proxy
• smart reference

The kind of proxy that the message_queue type needs is combination of the last 2 that offers:

• Access to the head and tail of the message queue via its various private enqueue and dequeue member functions.
• Counting the number of references to the message queue and closing it down when either there are no more interested consumer(s) or the producer(s) have finished producing. 

Okay so the design choices are to either:

1. Have a zoo of some_message_queue types each with member functions for generating their own proxies that use the extremely useful friendship C++ language feature[2]
2. Select a specific some_message_queue policy from the zoo and wrap it in a generic message_queue type which dishes out the head and tail proxies.

Well at least there is no goat in this problem so in true Monty Hall style 

"Let's see what's behind door number 2..." 

Online Collaborative UML Modelling - GenMyModel

www.genmymodel.com It's really rather good!

GenMyModel Log in from and link to your github account, it's really rather good and I'm not the only one[1]

References:

[1] stackoverflow: Tools for creating Class Diagrams

Simplification of logging services.

As Thoreau said: "Simplify, simplify, simplify..."

The trouble with writing something in an hour or two that works is that you then have find your subconscious mind is chewing it over all the time that you're working on something else.

So it is whilst working on message_queue I couldn't resist fiddling with the logging services:

• the io namespace is gone
• serializor_policy is gone
• only the null_serializor remains renamed null_log
• ready for asycn_log
• logger now takes an output stream policy and is, consequently, more flexible
• works directly with any ostream decendent
• logger template overloads operator() 
• logger doesn't need a stringstream any longer 
• I've left the stamps alone, for now... 

TL;DR github.com/ifknot/libfbp

How it is... (2)

Part (2/3): A general purpose thread-safe internally synchronized message queue.

When it's time to end the relationship.

So here is the code for the single lock general purpose message queue as the obviously correct base queue type, but with one important addition...

The ability to close() the message queue.

But why?

TL;DR github.com/ifknot/libfbp

Part (1/3): A general purpose thread-safe internally synchronized message queue.

"The English can form a queue of 1"

Flow-Based Programming (FBP) [1], Communicating Sequential Processes (CSP) [2] and Active Objects (AO) [3] rely on message passing between otherwise environmentally opaque conccurent components. 

There are lots of ways of providing this communication[4], be that synchronous or asynchronous, but one of the most frequently used is that of a message queue.

The principle reference for my development of the concurrent queues is the, totally excellent, The Art of Multiprocessor Programming (Herlihy & Shavit 2008)