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

From: Scott Woods (scottw_at_[hidden])
Date: 2007-06-13 18:12:40

----- Original Message ----- 
From: "Yigong Liu" <yigongliu_at_[hidden]>
To: <boost_at_[hidden]>

> 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.

Pointers to async/synch-derived types, where async/synch are 
boost::noncopyable
starts to look pretty sane.

>> 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.

Yes. I have this lingering feeling that it is a cute abstraction at language
level that relieves the developer from the headache of concurrency. Just 
right at
this moment I think I have a chord-ache.

> 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

While SDL was intended for broad use (system modelling) there has
been significant uptake with those people writing state machine 
specifications.
Some of the ITU-T telephony protocols are documented in SDL. SDL
is a good tool for that domain.

My interest in Join arises from a perceived overlap of concurrency and
FSMs.

> 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.

OK ;-)