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

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

Hi Yigong,

Could the difference between your join-based applications and other 
seemingly
similar applications be characterized in the following way?

Two different areas of activity for me have been running (small) projects 
and
also developing highly asynchronous (i.e. event driven) software for the
telephony world. As projects get bigger its harder and harder to ignore
techniques such as critical path analysis. This technique most obviously 
brings
some order to proceedings but it also identifies instances of concurrency. 
Through
that concurrency the finish date is earlier than it otherwise would be.

Is your "joining" library a tool for implementing the results of a software 
concurrency
analysis? Rather than something targeted at the implementation of the highly 
interactive
entities in a telephony protocol?

Cheers.

----- Original Message ----- 
From: "Yigong Liu" <yigongliu_at_[hidden]>
To: <boost_at_[hidden]>
Sent: Tuesday, May 22, 2007 6:41 PM
Subject: Re: [boost] Boost.Join - asynchronous concurrency library based 
onCw and Join Calculus

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