Re: [boost] Boost.Join - asynchronous concurrency library based on Cw and Join Calculus

From: Yigong Liu (yigongliu_at_[hidden])
Date: 2007-05-22 02:41:41

> Is it really lock free? I see you are using boost::mutex, and I see no
> atomic ops. Unless you are cleverly using boost::shared_ptr for some
> kind of lock free queue

Hello,

By "lock-free", i am referring to the fact that in Join (or Cw) based
applications, there is NO explicit usage of threads and synchronization such
as locks. I am not referring to particular lock-free data structures or
algorithms. It is more about programming model change; from the model of
shared-state (protected by locks or other synchronization primitives) to the
model of orchestration of async and sync concurrent activities. Although the
code of applications based on Join do not contains locks, the code generated
by Join templates do contain mutex and conditional variables. In other
words, Join (and Cw) "hides" "low level" threads and synchronization from
applications code by providing a high level API of async / synch methods and
chords which allow flexible and direct specification of concurrency and
synchronization.

There are drawbacks with constructing concurrent applications directly using
threads and locks. Java's executors and concurrency utils and Intel's
threading build blocks provide many high level constructs to address this
issue. IMHO, Join (Cw) 's minimal toolset of async / synch methods and
chords are more "fundamental" in that it can easily encode many other high
level constructs.

In Java/C#,  the basic synchronization idiom is synchronized methods which
hold locks from begining of method.  In Join (Cw), synchronization is
defined by chords (join-patterns). Chords are declarative in that they
explicitly specify the set of methods need to be called so that the chord
body will execute. And when chord body runs, no lock is held anymore. So any
synchronization needed must be specified and satified in header.

Thanks for looking into it.
Yigong