Re: [Boost-users] Does anybody interested in active object

Subject: Re: [Boost-users] Does anybody interested in active object
From: Dean Michael Berris (mikhailberis_at_[hidden])
Date: 2010-11-07 21:29:02

On Mon, Nov 8, 2010 at 7:11 AM, Marat Abrarov <abrarov_at_[hidden]> wrote:
> To Dean Michael Berris:
>> You'd be better of doing data parallelism with Boost.MPI
>
> No. Because I'm speaking about thread-based parallelism (with shared memory
> access).
> Processed-based parallelism and IPC supplement
> but don't replace thread-based parallelism in general.
>

Well, which is why I said 'data parallelism'. This implies a whole
different kind of programming, which doesn't typically include threads
and synchronization. ;)

>
>> 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)
>
> Tie this tasks with the data they share and You will have an active object.

Nope, sorry, that's not an active object. An Active Object requires
that you have a at least one thread of execution dedicated to the
active object, and that you have a synchronous interface to that
object.

> If the tasks don't have shared data - they don't need an active object.

Active Objects really have nothing to do with shared data. It's a
design pattern that prescribes a way of isolating the synchronization
and serialization of operations applied to an object that is assumed
to be shared across multiple threads of execution. The way the active
object does it is by lining up the operations to be performed
asynchronously and perform those in a different thread of execution.

You can implement an active object without involving shared data --
for example you want to model a processor, or a math kernel, which
does all its work on a single thread because maybe you have a library
underneath that is not thread-safe. In situations like these it makes
sense to have an active object implementation.

> I think - active object is built on task-based parallelism
> but it does not mean that "active object" should replace
> "task-based parallelism" everywhere.
>

I think you have it wrong. The active object pattern is a design
pattern that doesn't know about task-based parallelism. Task-based
parallelism is a different pattern and different paradigm altogether.
The active object pattern by itself is just a design pattern, nothing
more.

>
>> But what you're describing is not the active object pattern. ;)
>
> http://en.wikipedia.org/wiki/Active_object
> http://en.wikipedia.org/wiki/Active_object_(Symbian_OS)
> What about ma::echo::server::session class - is it an active object?
>

I haven't looked at your examples, because I was only commenting on
the issue regarding massive parallelism. Maybe when I have enough time
I'll look through your examples. ;)

>
> http://www.boost.org/doc/libs/1_44_0/doc/html/boost_asio/example/chat/chat_c
> lient.cpp
> Is chat_client an active object? If "yes" then why?
> chat_client::write have no completion callback - and this is not enough
> sometimes
> (I can say "always", if You don't implementing "fire-and-forget" logic which
> is rather seldom).
>

No, this is not an active object. An active object has its own
lifetime thread. In this situation the lifetime thread is shared
between Boost.Asio's IO subsystem and all the ASIO related handlers.

Also, you don't need a completion callback for a class to model the
Active Object pattern. You can create methods that return 'void' and
just execute the actions asynchronously in its own lifetime thread.

>
> http://www.boost.org/doc/libs/1_44_0/doc/html/boost_asio/example/serializati
> on/connection.hpp
> s11n_example::connection is an active object and have completion callback...
> but it's much simpler then ma::echo::server::session_manager - I try to
> suggest "samples" that can help
> to build such a kind of complex active objects.
>

Nope, sorry, s11n_example::connection is not an active object. What it
actually is, is an execution context -- or sometimes people call it a
continuation, a generator, or a state machine. Because you're using
the execution context relevant with a particular connection, it
doesn't imply that the operations are performed on a different thread.

All this is doing is encapsulating callbacks and the protocol
implementation into an object. It exposes a means of asynchronously
scheduling operations, but it doesn't hide these details from the
interface. The goal of the active object pattern is to hide the
asynchronous nature of the implementation from the user of the object.

>
> http://www.drdobbs.com/go-parallel/blog/archives/2009/09/parallelism_sho.htm
> l
>> We are surrounded by parallelism even more so that serial activities.
>> Social and biological systems are immersed in parallelism and these
>> systems have worked out the kinks over millions of years.
>> In biological systems, independent units perform simple computations
>> or activities independently and in parallel.
> and
>> IMPLICATIONS FOR COMPLEX REALTIME SYSTEMS:
>> Complex real-time systems would be a sea of state machine objects
>> interacting with each other. There will be low level state machines
>> which would work together to implement high level state machine behavior.
>
> Here's the place for active object pattern.
>

If you have unlimited number of cores and no limits on the number of
threads you can spawn for each active object you create, then yes.
Otherwise, you can stick with continuations, asynchronous completion
handlers, and just plain data parallelism.

The place for an active object is where you have to expose a
synchronous interface to a resource which underneath performs the
actions asynchronously. This is like the half-sync half-async pattern
which, once you understand, is what the active object implementation
provides.

-- 
Dean Michael Berris
deanberris.com