Re: [boost] a new release of "Join" asynchronous concurrency library

From: Yigong Liu (yigongliu_at_[hidden])
Date: 2007-06-13 12:44:29

Hello,

On 6/12/07, Scott Woods <scottw_at_[hidden]> wrote:

>
> The oldest solution in C/C++; pointers to?
>
> eg;    vector<async<...> *>
>
> smart_ptrs?
>
> I can also vaguely guess why you would want vectors of async/synch but
> vectors of actor? Isnt it a base and therefore vectors of base would
> involve
> slicing?
>
> Don't fully understand the problem space so I wont be embarrassed if these
> are ignored.

Thanks for the suggestions. Indeed i am thinking that maybe i should use
vector<async<void(data)> &(*)> in the first place. The specific application
case for this is when we apply Join to some applications of orchestration of
data flows. Suppose we are writing code to collect data from 16 external
data channels, we can define useful orchestration/synchronization patterns
over these channels, e.g. when channel 4,5,6,7 all have data arrived, we
call handler method1, when channel 6,7,8,9 have data available, we call
handler 2. So users don't want to define/handle each specific channel. By
using vector<async<> > (without &/*) i can create a bunch of channels in one
shot, which is quite useful. Maybe i should look into some kind of var-array
for this purpose.
Allowing copying of actor/async/synch objects are dangerous and could mess
up how Join works. Each of them maintains status info about on-going
messaging. Cw discourage the copying by only allowing defining async/chords
in "class" objects which are instantiated from heap and disallowing their
use in "struct". I am trying to boost::noncopyable for this.

Still learning Join. Its going to take a while. At language level it's quite
> simple
> but the underlying model is less so and is "outside the box". The best I
> can
> do at
> the moment is try to translate the examples into SDL. For reasons I have
> not
> truly clarified this translation is only successful in one direction, i.e.
> Join ->
> SDL. I suspect that the systems expressible in SDL may be a superset of
> those expressable in Join. Or more Join-based code is required to support
> the more complex SDL systems.
>
> Its a bit of a struggle and I dont know that the comparison is even valid.

You are not alone.  Generally I  found Join does require a bit of mindset
change. When i develop the samples, often i found i am back to mindset of
shared-memory/locks state, need a bit of effort to adjust it. There are some
design "idioms" related to Join, which i collected from the join/Cw papers i
have read, i put it in the section of document "OO concurrency design based
on Join". Chord is the core of design which defines asynchrony,
synchronization and concurrency at the same time.
Regarding to the translation between SDL and the Join library, first they
are tools for different purposes. The Join library is to provide a minimum
set of primitives to build asynchronous concurrent applications, its focus
is good integration with C++ language and library features (inheritance,
copying...); while SDL is more system modelling and analysis (i dont know
SDL, please correct me if i am wrong). Definitely SDL will have more
facilities for modeling purpose; If you can find some modeling tools based
on Join calculus, that may be more comparable. Also Join's core is
asynchronous. I dont know much about SDL and modeling, so please dont take
my words too seriously.

Thanks
Yigong