Effective Concurrency: Prefer Using Active Objects Instead of Naked Threads

8 thoughts on “Effective Concurrency: Prefer Using Active Objects Instead of Naked Threads”

1. Состоятельный человек ищет себе девушку
   для настоящих
   отношений, параметры параметры: от 18 до 20 лет рост
   до 175 см. волосы светлые, модельное телосложение. личный помощник т.79262036777 Руслан
   теги:
   объявления знакомства
   знакомства через интернет

2. Pingback: Let’s try the new C++0x type of Active Object | Kjellkod's Blog
3. Thanks for yet another great article Herb.

   I think that instead of using Message objects (for pre C++0x developers) it could be benificial to follow the idiom of generic function callbacks ( your Gotw: 83 et.al ).

   This way you can easily make the Active object and Backgrounder without message objects focus on the core with cleaner code as a result.

   Inspired by your Effective Concurrency Europe 2009 seminar I ended up with something like this :)

   I.e. : (cut-down & pseudo-ish version)
   Class Active {
   private:
   ….
   void run() {
   while(!done){
   smart_ptr msg= mq.pop();
   msg(); // executes msg
   }
   }

   public:
   ….
   ~Active() {
   send(bind(this, &Active::DoDone));
   thd->join();
   }
   ….
   };

   class Background {
   …
   public:
   void Save(smart_ptr data) {
   active->send(bind(this, &Background::DoSave, data);
   }
   …
   };

   Standard pre C++0x but still with the clean look thanks to some template touch :)

   Cheers

4. @Thomas: Yes, function follows the rule of all function objects — they are intended to be cheap to copy. So if you want to avoid copying state, hold it by pointer/shared_ptr.

5. Very nice and detailed article. So nice, that I went head ahead and try to use it in one my program.
   From this experience, I get some concern about the C++0X way. While I really like the terseness of it, it seems to be a bit more error-prone and can become inefficient if you don’t pay close attention.

   In my case I wanted to pass a Medium-sized data to an active object. By medium-sized I mean a piece of data big enough that you can afford to copy it one time for the purpose of thread isolation, but NOT many times. (for example a buffer of char[4096])

   It worked very easily with OO style message.
   struct MMediumSized
   {
   MediumSizedData data;
   MMediumSized(const MediumSizedData& data):data(data){}
   void Execute(){…}
   }

   void foo(const MediumSizedData& data)
   {
   a.Send(std::unique_ptr(new MMediumSized(data)));
   }

   The Send() function forced me to do the right thing, thanks to taking an unique_ptr as parameter. The MediumSizedData is copied *once* into the message (in the constructor of MMediumSized) and then the unique_ptr to the message is moved into the message queue, then moved out, get executed and then get automatically destroyed.

   I hit way more problems when moving to lambda and std::function. My first impulse was to do :

   void foo(const MediumSizedData& data)
   {
   a.Send( [&data](){ …} );
   }
   I didn’t pay enough attention that the data was captured by reference, so there is no copy at all which cause data race in the program.
   Then I changed to :

   void foo(const MediumSizedData& data)
   {
   a.Send( [data]() {…} );
   }

   The program was correct, but way slower than the OO version. I put some traces into MediumSizedData copy constructor and realized that every time I called foo() and the message was executed, MediumSizedData get in fact copied 5 times !! It seems that’s because std::function really love to make copy. I cannot figure out what happen exactly in the internals of std::function but is seems that my lambda get copied a LOT inside.

   So I finally realize that you have to use a shared_ptr to get the right semantics :
   void foo(const MediumSizedData& data)
   {
   std::shared_ptr data_copy(new MediumSizedData(data));
   a.Send( [data_copy]() {…} );
   }
   I would prefer an unique_ptr but unfortunately it seems that std::function make always a copy of its internals and never a move.

   TL:DR :
   It’s very clear in the OO style that you dynamically allocate a message and then only manipulate and pass a *pointer* around whereas the std::function way looks more mysterious. What really happen when I construct a std::function from a lambda ? What really happen when I a push a std::function into the message queue ?

6. I’ve been hoping for some focus on actor-model type concurrency and more focus on futures/messages, etc.
   Thanks Herb =)

7. Yes, no specific ETA but not before next year. In the meantime, they are all freely available via the links above.

8. Hi,

   Excellent read.
   Are you planning to compile all the column in the book?

   Thanks

Comments are closed.