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

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

boost.org
> [mailto:boost-bounces_at_[hidden]]On Behalf Of Hurd, Matthew
> Sent: Tuesday, February 17, 2004 4:31 PM

thanks for the numbers!

excellent stuff. would like to add the note that in an "ideal"
deployment of the ActiveObject pattern, it brings zero overhead.
thats a wee bit sensational to make the point. but the overheads
incurred with mechansims such as inter-thread messaging were
there anyway. so yes copying, queueing, dequeueing and signaling
a thread all consume cycles. but the application would have had
to do something similar. ActiveObject is just a formalization
and acknowledgement of it.

> 
> Threading is a big overhead though.  Consider these numbers:
> 
> Safe increment           (Athlon 2800+)    (P4 3.2GHz)
> Interlocked primitive        11 ns            53 ns
> Critical section            138 ns           411 ns
> 

<snip>

> > 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.
> 
> Not sure I agree.  Think of it the small talk way.  A message is a
> method call.

hmmmm. tangle with this one all the time and only have bruises
and piles of discarded source to show for it :-(

yes, smalltalk was the original and it did reinforce the notion of
message vs method (it has "proper" dynamic binding).

there are two hidden nasties here (IMHO). first is the assumption
that when we "send a message" this is directly mapped to a method.
once you have active objects up and... active? the messages go
through a "strange and wonderful" morphosis. they do not directly
match the methods in the active object. the messages reflect the
_interaction_ that is occurring. analogies can be drawn with the
use case concept, where actors work through interactions with the system.
active objects interact rather than make calls to each others methods.
but that is probably a sad abuse of uml.

secondly, sync calls (i.e. C++ methods) that internally queue messages
that are eventually processed and result in calls to (other?) methods
in the same C++ instance implies that the callers i/f and the servant
instance are one-and-the-same. among other things this leads to a
difficulty in separating servant code from the client.

i'm tiring :-( i feel good about the goal but there is a point of
critical mass that feels like its constantly moving away. and i
had better do some "real work" for a while.

hope there has been sufficient content and clarity in my messages

cheers,
scott