Does anybody interested in active object pattern?
Hello, Boost C++ Libraries' community. I'm trying to develop the idea of (most effective) building active objects by means of Boost C++ Libraries (not as libpoet does). I chose for this Boost.Asio as the only library supports flexible "custom memory allocation" mechanism. Here is my project: https://sourceforge.net/projects/asio-samples/ And here is short description of the concept: https://think-async.com/Asio/Examples This project isn't a library and won't be it. It is something like advanced examples for Boost.Asio. And I hope this "advanced examples" are very close to production-level code. Does anybody interested in active object pattern for massive parallelism by means of C++? (Intel TBB doesn't offer a similar approach) Regards, Marat Abrarov.
On Sat, Nov 6, 2010 at 10:56 PM, Marat Abrarov <abrarov@mail.ru> wrote:
Does anybody interested in active object pattern for massive parallelism by means of C++? (Intel TBB doesn't offer a similar approach)
I'm not sure how you think active objects help for massive parallelism because the active object pattern implies that you're serializing operations on a single object. I've used Boost.Asio to implement Active Objects but only in cases where it makes sense -- like for example a concurrent accumulator or a concurrent resource handle (log sink for example). You'd be better of doing data parallelism with Boost.MPI and/or Boost.Asio's io_service run on multiple threads, and having independent tasks multiplexed across a number of processors (either through processes or threads). I remember reading about Microsoft's efforts (through Herb Sutter) to introduce an "active" extension to Microsoft Visual C++, where you can easily make classes that instantiate to active objects. I'm not sure where that effort is now though. HTH -- Dean Michael Berris deanberris.com
On 07/11/10 05:58, Dean Michael Berris wrote:
I'm not sure how you think active objects help for massive parallelism because the active object pattern implies that you're serializing operations on a single object. 1/ Put data workload in a concurrent queue 2/ Spawn objects eating the queue asynchrnously 3/ ??? 4/ PROFIT
I don't see the limitations here.
On Sun, Nov 7, 2010 at 4:28 PM, joel falcou <joel.falcou@lri.fr> wrote:
On 07/11/10 05:58, Dean Michael Berris wrote:
I'm not sure how you think active objects help for massive parallelism because the active object pattern implies that you're serializing operations on a single object.
1/ Put data workload in a concurrent queue 2/ Spawn objects eating the queue asynchrnously 3/ ??? 4/ PROFIT
I don't see the limitations here.
But what you're describing is not the active object pattern. ;) An Active Object is an object that: 1. Has a synchronous interface -- meaning an API that allows you to deal with it like a normal (C++) object. If any function returns a value, it would have to return a handle to that future value (the active object pattern is intimately tied to the Future and Promise patterns). 2. It serializes operations applied to the object in a single or multiple threads of execution. An active object is said to have its own lifetime thread, which it manages itself (presumably through RAII). 3. It has normal reference semantics, but does not imply value semantics. This means an active object may be referred to through proxies or through shared references/pointers to an instance of the active object. There are some active objects that enforce the non-copyable invariant, which makes the only useful handle be either a shared pointer or a proxy of a different sort. There's much about the Active Object pattern that is important in allowing for consistent interfaces to allow traditionally non-concurrent code to deal with objects that know how to deal with concurrency. HTH -- Dean Michael Berris deanberris.com
But what you're describing is not the active object pattern. ;) An Active Object is an object that:<snip> Oh my bad :o
On 07/11/10 16:51, Dean Michael Berris wrote: then again, can't we have an Active Object taking care of an future result of computation and have it spawn itself other AO working on subpart ?
On Mon, Nov 8, 2010 at 12:05 AM, joel falcou <joel.falcou@lri.fr> wrote:
On 07/11/10 16:51, Dean Michael Berris wrote:
But what you're describing is not the active object pattern. ;) An Active Object is an object that:<snip>
Oh my bad :o
No worries. :D
then again, can't we have an Active Object taking care of an future result of computation and have it spawn itself other AO working on subpart ?
Yeah, but that would be wasteful. You can make the active object do a fork-join implementation internally if you have lots of data to work on. Typically tough, active objects are great for things like a log sink -- where the sink just takes in all the log entries and serializes them to be written in batches -- or for RPC handles. Think more like if you represented a remote machine/resource through an object, you'd want to have the I/O and all the mutations to be done in a serialized/sequential/synchronized manner. HTH :) -- Dean Michael Berris deanberris.com
participants (1)
-
Dean Michael Berris -
joel falcou -
Marat Abrarov