From: Scott Woods (scottw_at_[hidden])
Date: 2007-05-23 18:06:13
Could the difference between your join-based applications and other
similar applications be characterized in the following way?
Two different areas of activity for me have been running (small) projects
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
some order to proceedings but it also identifies instances of concurrency.
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
analysis? Rather than something targeted at the implementation of the highly
entities in a telephony protocol?
----- Original Message -----
From: "Yigong Liu" <yigongliu_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
> 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
> 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
> model of orchestration of async and sync concurrent activities. Although
> code of applications based on Join do not contains locks, the code
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk