On Thu, Dec 18, 2008 at 4:55 PM, QPlace
Andreas Masur
writes: On Dec 17, 2008, at 10:09 AM, QuitePlace wrote:
Another look at this question is - should one program the inter- process/inter- thread communication first and worry about multi-core later? Or something should be planned at the development stage?
As with other areas such as exception handling etc., I would advise you to take multi-core technology into account at design time. Programing efficiently for more than one core is certainly not as easy as making cookies and thus if you don't plan up front you are likely to lose efficiency later on. Especially in your example about interprocess/interthread communications.
Ciao, Andreas
This is exactly what worries me. Should that planning be done "outside" of boost framework? For example, if I am using features provided by ::interconnect library - how am I suppose to take multi-core technology into account if, say, "shared memory" already locks me into a solution where I don't have much control on anything multi-core and where "multi-core" is not even present as a concept?
Your comments are very much appreciated
Just some side comments on multi-cpu program design. If you want a program truly multi-cpu, without slowing down the more cpu's you access, then the programming style you would need to use is the Actor style, or one of its kin. Basically you need to treat every Actor as its own state, pretend there is no such thing as global state, so do not use statics, no globals, etc... It is not easy to do in C++, but it can be replicated well enough. Your problem domain will also need to be easily separated so it can be operated in parts, if it cannot then you have a bigger problem then just the design, and almost all programs can be split up to some extent. Read up on the Actor model, it will give you plenty of ideas. Perhaps work with Erlang a bit to get a feel for the Actor style. The knowledge you come away with is invaluable for designing scalable multi-threaded apps.