Re: [Boost-users] boost::interprocess, shared memory and multi-core

Subject: Re: [Boost-users] boost::interprocess, shared memory and multi-core
From: OvermindDL1 (overminddl1_at_[hidden])
Date: 2008-12-18 23:44:23

On Thu, Dec 18, 2008 at 4:55 PM, QPlace <quiteplace_at_[hidden]> wrote:
> Andreas Masur <amasur <at> gmx.de> 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.