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