RE: [boost] Re: [Threads] Simple active object wrapper, take 2

From: Darryl Green (Darryl.Green_at_[hidden])
Date: 2004-02-20 03:11:50

Hi Matty,

> -----Original Message-----
> From: Matthew Vogt [mailto:mvogt_at_[hidden]] 
> Subject: [boost] Re: [Threads] Simple active object wrapper, take 2
> 
> Actually, the paper does note that for performance reasons, 
> the thread could
> be replaced with a thread pool.  This requires support, 
> however, in that the
> Method Request needs to be able to lock the resources needed 
> to perform the
> task prior to doing so.

I haven't read the paper you mentioned, but I do have POSA volume 2 by
Schmidt et al in front of me. Based on the description in it, your code
definitely does (very cleanly) provide a way to implement the active
object pattern.

> 
> In terms of my wrapper, the object wrapped needs to have 
> 'hooks' for locking
> its resources, and the active<> wrapper class would need to 
> have a policy
> class to perform the 'Scheduler' role, which knew enough to 
> use the resource
> locking hooks.

I don't see a great deal of use for the thread-pool based active object
variant briefly described in the book, where the active object has a
whole thread-pool to itself and the object needs its own internal
locking. This seems to me to be an implementation detail of the object
itself - nothing to do with the active object model. Further I have real
difficulty imagining a circumstance in which I'd want all those threads
sitting around dedicated to one AO (like I can talk...). However, it
sounds like you are describing something different.

I can (if I try hard enough) imagine that I'd like to specify the level
of concurrency allowed between  methods of an object and have a
scheduler clever enough to order the execution of those methods
efficiently based on this (and probably request priority as well) on a
(shared by multiple such AOs) thread pool.

A dynamic thread pool could then scale the number of threads used based
on the actual observed/required concurrency.

However, I suspect that the above isn't going to fly, if only because it
is likely to make the scheduler a bottleneck. Anyway, nobody seems to
want to give me a box with enough processors and I/O to make this much
fun - and I can't think of anything (useful) to run on it :-)

Is that anything like what you had in mind?

Does anyone actually re-use some of the more exotic veriations of these
patterns often enough that they consider a framework for implementing
them is actually anything more than a (fun?) excercise?

Regards
Darryl.

##########################################################################
This e-mail is for the use of the intended recipient(s) only.  If you have 
received this e-mail in error, please notify the sender immediately and 
then delete it.  If you are not the intended recipient, you must not use, 
disclose or distribute this e-mail without the author's prior permission.  
We have taken precautions to minimise the risk of transmitting software 
viruses, but we advise you to carry out your own virus checks on any 
attachment to this message.  We cannot accept liability for any loss or 
damage caused by software viruses.

##########################################################################