-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org]On Behalf Of Jeff Garland Sent: Friday, February 13, 2004 3:58 PM To: Boost mailing list Subject: RE: [boost] Future of threads (III)
This reminds me of the actor model of distributed computation. If you are familiar with actors, could you briefly compare/contrast your approach against them?
i know of uml's actor but not sure if that's the same thing. and my knowledge of uml is so lame i suspect i shouldnt attempt any analogies.
I believe you'all are talking about 'Active Objects'. Doug Schmidt, primary author of ACE, has written extensively on this subject. Take a look at this paper:
Thanks. AOs have a significant number of similarities with the model that I have been working with; e.g. scheduler, servant. There are also some differences. Some of these can be considered implementation specifics while others are differences in design goal or underlying paradigm. Method Request is the object sent by a client, queued in a scheduler and performed within a servant. The AO pattern defines a request+results model, i.e. an asynchronous modeling of the traditional synchronous call (arguments = requests, results = return value). The pattern does allow for deviation from this model with one-way methods. For several reasons I have found this "unsuitable". Firstly the adoption of "method" as part of the vocabulary is unfortunate (at least, according to me :-) It brings with it "synchronous baggage". A strange symptom that I have encountered is a difficulty in separating client code from server code, i.e. clients sometimes include a quantity of inert and redundant server code. Also, the interaction with servants tends to involve more than a single exchange (request+result). A much more flexible model can be built on a "send" primitive (i.e. from SDL) which achieves something very similar to the internal workings of AO "methods". This breaks away from the Q+A model, allowing for "one-way", "two-way" or "any-old-way". The relative "looseness" of send vs method can be too much for some. It could be argued that a one-way method allows for all of this. As long as that facillity is buried within the larger method-based document then I think it is too effectively mis-represented. The "method-based" thinking also results in C++ classes with methods that translate to each of the messages that might be sent. In my book this is tantamount to the servant claiming ownership of the protocol. I'll skip the tedious explanation of that one and just say "i really struggle with that one". There is some notion of "a main application" and servants or schedulers that might be available. I question why there is a distinction. The transfer of a Method Request to a servant is so similar to the transfer of results back; to not use the same technique seems almost tragic. I have applied the alternate model into existing frameworks and been pleasantly surprised, i.e. it was easy to present "theApp" (MFC/AFX) as a scheduler. A difficulty inherent in "breaking away" (from the method model) are the objects that are exchanged (previously "Method Requests"). In the new model these objects have some very interesting (i.e. painful) requirements. I'll skip another long explanation for a time when someone actually wants it :-) Thanks again for the reference. It is material I definitely needed to cover. I think it was very close but did have different goals. Cheers, Scott