RE: [boost] Re: Re: Future of threads (III)

From: scott (scottw_at_[hidden])
Date: 2004-02-16 21:27:21

> -----Original Message-----
> From: boost-bounces_at_[hidden]
> [mailto:boost-bounces_at_[hidden]]On Behalf Of Hurd, Matthew
> Sent: Tuesday, February 17, 2004 12:44 PM
> To: Boost mailing list
> Subject: RE: [boost] Re: Re: Future of threads (III)

> AO's should either have a queue for work or hook into a 
> queue.  They are
> a bit like a worker pool with one worker ;-)

yep.

> 
> Another idiom is a future value, where you ask for a value and don't
> block until you "read" the value.  ACE also has an implementation of
> this.  You can think of it as a bit like overlapped I/O.

Yes. This was also in the ActiveObject pattern. It was on the "client-
side", i.e. available to the thread that submits Method Requests as a
means to acquire the results.

While I understand its place in the ActiveObject pattern I would hope
that if a boost::active_object came into existence, there would be a
single (i.e. not _simple_) mechanism by which data passed from one thread
to the other, with an associated notification. In a behavioural sense,
the future mechanism wouldnt be appropriate for this.

This way of thinking does require that all threads are active_objects
which may be too aggressive <shrug>. A small sample of empirical data
says its fine.

> I also advocate a different architectural neutral style where you can
> have things at look like function calls that can be:
>     1.   a function call
>     2.   a call to queue work pool or active object
>     3.   an IPC mechanism for same machine transfer, e.g. 
> shared memory
>     4.   a network mechanism, TCP, UDP, TIB or something, for 
> 

Understand the reasons you ask for 1...4 but would like to add some
other thoughts to see what you think.

An ActiveObject servant contains code. That code is implementation
of behaviour and its what (I believe) we tacitly want when we all
say that "thread-inherited-classes" or "active objects" are a nice
manner in which to deal with threads.
(note: more accurately the pattern says that thread==scheduler and
a scheduler executes servant code. but i think we can skip this
detail)

If the code is in the servant, what do 1 and 2 mean? My best matching
of your thinking with the servant-based thinking would be that somehow
the "client" can submit something into the "worker pool" that _identifies_
a function that is in the servant. It would be nice if this "work
submission" could carry some arguments for presentation to the servant.

A detail that I am labouring is the separation of "calling" (would
much rather that this was "sending") and execution. Our active object
has no synchronous i/f with methods for us to call; it is simply a
"work pool" that we add to. As soon as we make a sync i/f available
then we go down that road that leads to servant code in the client.

I suggest that notions of "function call" should be exorcised from
discussions that are targeting active objects. That type of thinking
is perfectly valid in some other thread (oops) but can scuttle work
targeting active objects; the behaviour (i.e. the code) is inherently
in the object.

a client can only submit "worker orders" or "Method Requests" or
jobs or messages or signals.

I hope there is enough there to make a case :-)

> If it can be enabled by a policy driven approach then you can 
> change the
> architecture of your application by simply changing policies.
> 
> I think David Abraham's named parameters could help greatly with this
> approach, along with the serialization lib for marshalling support.
> This should provide a solid basis for this.  I've also thought that
> perhaps boost::signals might be the correct approach to take for this
> but I'm unsure.
> 
> To support this approach you also need mutex aspects that are also
> policy driven.  I am preparing to submit such locking that 
> builds on the
> existing mutexes and locks.

<phew> That is quite a scope. But yes, I can see that ultimately
it should cover all these dimensions. Maybe a phasing?

Cheers,
Scott