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

From: Giovanni Piero Deretta (gpderetta_at_[hidden])
Date: 2007-06-13 05:57:35

On 6/12/07, Yigong Liu <yigongliu_at_[hidden]> wrote:
> 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.

Nor should be, they are mostly low level optimizations.

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

I'm not really familiar with either the implementation of the Join
library nor with lock-free design, but from a quick glance at the
code, I see in boost/join/base/port.hpp:asynch_f [1] that you use
mutex protected deque to enqueue async calls. This is probably one
place that would benefit from a lock-free deque; also probably the
fact that the max queue size is bounded might help with this
optimization.

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

Not at all. Plain well designed lock-full (?) algorithm are fast
enough 99% of the times (even as fast as lock-free). Is just that a
more optimized implementation would cover even the remaining 1%. Do
you have any benchmark? And not just synthetic benchmarks, but some
real application written with both classic locks & condvars and with
Join patterns. This would be useful to compare both the benefits in
code simplicity and in performance (if any). Even if Join where
slower, if it would really simplify the design of concurrent
applications it would be a win.

> Could you expand on this a little more? if you can use Join's
> implementation as examples, it will be more educational for me.

Really, I've only taken a glance at the implementation, it seems
pretty complex and it will take a while for me to understand it. But
I'm very interested and will look more into it as soon as I have time.
Some implementation of design documentation would be greatly useful,
but I think most of it can be deduced from the Microsoft papers, is
that right?

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

I'm a big fan of asynchronous programming in general, and this is why
I looked at the Join library.

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

I would put STM and lock-free on a lower abstraction level than
futures, Join and deferred methods. The latters can be implemented on
top of the formers.

> You may want check out other boost concurrency
> libraries such as the futures and defer library by Braddock Gaskill.
>

I do. I'm waiting to have a real concurrent project to try out those
abstractions. And yes, Join too.

> Thanks for looking into Join.

Thank you for writing it in the first place!

gpd

[1] I've the release marked boost_join_r1, so It might not be current.