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

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

Hello,

On 6/11/07, Giovanni Piero Deretta <gpderetta_at_[hidden]> wrote:
>
> AFAIK, Intel does use lock-free techniques heavily in its thread
> library to wasting time on concurrency primitives,

You correctly point out that the Join library does not contain or depend on
lock-free algorithms. The implementation of Join library follows the design
outlined in "Compiling Join-Patterns" paper and further developed in JoCaml,
Comega and C#.Joins. It explores using C++ template programming to capture
the design idea and optimizations developed thru this lineage of languages
and libraries. Indeed specific lock-free algorithms and data structures are
not in the design consideration.

so I do not think
> the current implementation of your library would compare favorably
> with it. On the other hand, I do not see why the same techniques
> couldn't be applied equally to your library.

Could you be more specific about the places in code and design of the Join
library where i should improve? My number one purpose of proposing this
library is to invite experts on this list to review its design and
implementation. Please be specific to the point to be helpful. Also i have
been talking to Microsoft researchers who developed Cw and C#.Joins library
to discuss design and implementation trade-offs and learnt a lot. Hopefully
based on all these feedbacks, the Join library can be improved to be a real
useful library.

You need to be an expert on lock free programming  (which I am not) to
> take advantage of it, and experts in this area are still uncommon, so
> you may have an hard time optimizing your library.
>

Are you considering libraries not based on lock-free algorithms inherently
inferior to or unoptimized compared with libraries with lock-free
algorithms? Could you expand on this a little more? if you can use Join's
implementation as examples, it will be more educational for me.
To me, what is best about Join is that its primitives (async/synch methods
and chords) supports a high level asynchronous concurrency programming
model: orchestration of asynchronous events/messages/data_flows, which is
well suited to developing today's asynchronous, distributed applications.
And these primitives happen to be fundamental enough so that you can use
them to encode various concurrency designs as demonstrated in over a dozen
tutorials.

There are many concurrency models, such as STM, futures and deferred
methods, and of course lock-free algorithms. Join is just one of them, and
it is not silver bullet. You may want check out other boost concurrency
libraries such as the futures and defer library by Braddock Gaskill.

Thanks for looking into Join.
Yigong
http://channel.sourceforge.net