Hurry Quick! There is Pandemonium on the Blackboard!
Things do get a bit dicey when one is in uncharted waters and decisions have to be made. This parallelism, multicore, and many core stuff has lots of different entry and exit points. We can have parallelism and concurrency at the hardware layers, operating system layers, network layers, database layers, application layers, design layers, and requirement layers.Typically each layer is handled by a different class of developer, designer/engineer. Each level has its own lingo and models. It can be easy for the uninitiated to get their wires crossed when talking about parallelism and the different layers. The old 'strategy vs. tactics' push can end in a quagmire quick. Quite frankly this can be some difficult stuff in the wild. Lots of werewolves and no silver bullets. We can't in good conscience tell the uninitiated not to worry, just follow this 'a-b-c recipe' and purchase the 'get-er-done-tool' and you'll be okay. In fact, if you don't have some sort of formal computer science, software engineering, computer programming education then we would suggest you leave this parallel programming stuff alone until you have the proper background or have retained someone who does. Especially if the system you're involved in is going to see the light of day in terms of being used by the public or if you're being paid in some professional capacity. Of course, no one wants to hear public service announcements, but ... software development, software engineering, and designing software architecture is best left to folks who have obtained the proper and necessary education, training, and experience. Depending on its deployment, a software system can positively (or negatively) impact:
- public safety
- organizational stability
- business revenue/profit
- national security
- personal income/loss
and the reputations of practitioners in the software development/engineering field. Parallel programming/concurrency requirements can have a multiplier affect on poor designs. They have a way of shining the light on the weakest part of a design at the worst possible time. So we modify the traditional disclaimer to state don't try this at home or anywhere else unless you're really qualified to do so. As if public service announcements aren't enough, we also suggest even for the professionals an occasional visit to IEEE Std. 1012, IEEE Std. 1008, and perhaps just a sprinkle of the ACM Transactions of Software Engineeering and Methodology. Remember the ACM and IEEE journals are our friends. They often play the part of compass as we meander through the wilderness of complex computation and complex systems. Especially in these days of Clouds, Grids, Clusters, CMP CMT, and soon to come massive parallelism.
The truth is out that Tracey and I are foolishly but feverishly pursing solutions to a certain set of AI-Complete problems to which everyone knows that solutions are probably not forthcoming. The rumor that we are naively attempting to use massive parallelism and the ghosts of ICOT as our proverbial secret weapon and 'Voila' ace up our sleeve is sadly and pathetically true. But all is not lost. Among the models, paradigms, and architectures that we are using stand two true and tried problem solving models. So we aren't completely off the reservation yet. Where there is a model there is still hope. We like models, especially models that are true and tried. They tend to be well documented, with no shortage of examples or implementation. They tend to be well discussed in the literature. They make for great small talk between professionals. The prudent application of an appropriate model is often the difference between ending up with a rational, maintainable piece of software or a hustler's hack. For at least the past year or so, Tracey and I have been absolutely star struck by the possibilities of combining Pandemonium Architectures and Blackboards in the service of understanding and implementing massively parallel solutions to our AI-complete problems. We like both models/architectures because they are extremely flexible, scalable and suitable for describing solution models that require concurrency parallelism. Further both can be implemented using virtually the language of your choice. We were initially giddy over the idea of implementing the knowledge sources of the blackboard with pandemonium architectures. But we also found we could implement the blackboard structure itself with a pandemonium architecture. To make matters worse we found that any or all of the four layers of specialized demons in the pandemonium architecture could be implemented by blackboard knowledge sources or an entire blackboard structure. A ha! a multi-core moment at last! So the implementation that we like most (for the moment) is the blackboard implemented with a pandemonium architecture where the demons and control module can communicate to the blackboard knowledge sources. So what we have for the time being is Pandemonium on our Blackboard. Yep! We do start with models but for implementation and design, in this case, we're using C++, (Linux/Solaris 10), pthreads, Prolog, nedit, and emacs (LOL). For design we used basic, bread-n-butter diagramming tools: (tgif, xfig, umbrello).