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@gmail.com> To: <boost@lists.boost.org> 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