views:

662

answers:

1

Does anyone have any examples of the Blackboard concept from p.165 of 'The Pragmatic Programmer'?

I want to have several small sub-systems (DLLs and EXEs) mostly independent of each other. There are some assemblies that will be used by all EXEs. These assemblies will nearly all use the same database. Rather than using interfaces for communication between these assemblies, wouldn't a Blackboard type pattern provide more independence?

I'm thinking of some mediator type construct that notifies via events and all sub-system communication goes through it. This keeps the syb-systems very independent. The mediator will hold the name of all notifications it should broadcast. Subscribers will then listen to a particular event by name but always subscribe to the same (or perhaps pass name as parameter) mediator event.

Here's some more discussion on it: http://www.experts-exchange.com/Programming/Languages/C_Sharp/Q_22829492.html

+3  A: 

The concept of a blackboard is that multiple independent processes run and update the blackboard as they work out pieces of it. A classic example is speech recognition. The input data is the audio that is to be recognized. The audio can be segmented and multiple threads start matching the snippets to words. As each thread finds matching words, they update the blackboard with the translation up to this point. As phrases start to be assembled another thread can do grammar checking to verify the choices the various recognizer threads are making. If a word has a low confidence and violates the grammar, the piece can be rerun looking for alternatives. This might even result in re-partitioning the audio data as stutters and pauses are resolved.

As the phrases become sentences, even larger views can be taken and the various options for homophones (pair, pare) can be resolved. All of this is done by having the blackboard open to all of the processes and "locks" only being applied as they various results roll in.

Using a database as your blackboard makes some sense because you get transactions "for free", but it would depend on how aggressively the data is being updated and re-read. If it is happening very quickly the round trips would add up and make an in memory structure more reasonable.

Your idea of a mediator makes sense as it creates a single lock point... and blackboard algorithms rarely encounter the A->B, B->A style deadlocks because they ask for all the data elements up front. Beyond that, giving up on a lock isn't a large penalty as the various sub-tasks will be restarting all the time as the data rolls in. Subscribers to the board will need to be notified when the data they have has become obsolete, which could be done with callbacks which would restart the task with the newest data.

As far as the comment about a workflow: the major difference here is that most workflows are coordinated by a master process that takes the state just entered and makes decisions as to what states become available for the data to move within. While there may be independent actors, they rarely get involved in "outdoing" one another by creating better results (which other tasks will then use). In other words, a workflow is usually a very constrained set of states that data marches through, while a blackboard is almost a free-for all of independent activity. (That said, a blackboard could be behind your workflow: http://sunsite.informatik.rwth-aachen.de/Publications/CEUR-WS/Vol-247/FORUM_15.pdf)

I can't think of any C# examples of the pattern that I have seen, and the type of work I do doesn't have much call for it (the computations being deterministic). Doing some searches find references in other languages, but none that appear of great quality.

Godeke
Thanks. Wouldn't it work well as a central communication between distributed applications on an intranet?
4thSpace
It would seem a reasonable pattern for distributed applications with a few caveats. The first is that it normally is used in real time or near-real time scenarios where the overhead of more a complex model (which might avoid redundant computations more easily) is outweighed by rapid updates feeding the other processes better baseline data. The second caveat is that a blackboard trades speed of convergence for bandwidth: there can be a lot of redundant re-reads caused by the update/notify cycle.
Godeke
Because of those two potential problems I would definitely ensure that a more traditional network distribution model (such as using a design where a hub process distributes the workload to worker processes within the farm) doesn't make more sense. A bit more up front computation at the hub may mean that you can avoid most of the re-work by simply not sending commands to workers until the entire scenario is available for that unit of work. It is hard to say without knowing the nature of the work: iterative (Blackboard) or workload distribution (hub/worker).
Godeke