What does it bring that Channel does not?

Hello,

Yes, both Channel and Join are asynchronous messaging oriented. I have been working on restructuring/rewriting the internal of Channel, this is a offshoot from that work. In Channel, the join-pattern is implemented as two phase commit the same way as CCR did it. During the rewriting, for a comparison of simplicity and expressiveness, i really like to have a Join implementation in the original Cw (or Jocaml) style and here is the result. Internally the join-patterns are represented as bitmasks, many optimizations mentioned in Cw paper and implemented by Cw compiler ( http://research.microsoft.com/Comega/) are implemented by some template techniques. After using it to recode over a dozen Cw tutorial samples, i found it quite usable by itself and so i packaged it up and released it separately. In today's multicore world, people need high level tools for the orchestration of asynchronous and synchronous concurrent activities (besides distributed messaging and low level threads and synchronization), as evidenced by Microsoft continuous efforts on Join calculus (Cw, CCR(Coordination and Cocurrency Runtime), C# Joins lib) and Intel 's Threading Build Block library. Hope this small lib can be some help to our community. Also the API is "functional" oriented (we are talking about async / synch "methods') which may be attractive to people who dont like the explicit message passing API (send/recv) of Channel. With different API and different internal implementation, hope Channel and Join can find their applications. Thanks Yigong

What does it bring that Channel does not?

Hello, Here are a few more points to clarify the difference between Channel and Join: Channel's major purpose is to support asynchronous message passing thru "name spaces". Message senders bind to "names" in name space to send and receivers bind to "names" to receive. Name matching rules decide which senders and receivers will bind together and communicate. We could use linear / hierarchical / associative name spaces for different applications. Join intends to be a rather complete implementation of Cw asynchronous concurrency features. Its counterpart in C# is "Joins" library ( http://research.microsoft.com/~crusso/joins/index.htm). Channel's focus is to support transparent distributed message passing. Senders bind to names to send while the receivers could be threads in different processes or machines which bind to the same (matching) names to receive. Both senders and receivers dont need to be aware whether their communicating peers are local or remote. Join more focus on giving a good treatment of "local" orchestration of both async and synch concurrent activities. Join's primitives (async / synch methods and chords) are more "fundamental", in that we could use them to implement other concurrency idioms (such as semaphores, futures and active objects), In Channel, "join-pattern" is used as one of messaging coordination arbiters (choice and join) of pull dispatcher, one of many dispatching algorithms (including synchronous broadcast, round robin ...). It implements mostly the asynchronous part of Cw (thru two phase commit), in the same style as CCR ( http://channel9.msdn.com/wiki/default.aspx/Channel9.ConcurrencyRuntime). Compared with Channel, Join is a fairly small and simple library and header only. For more information, please refer to http://channel.sourceforge.net. Regards, Yigong

1. Is it a part of boost? 2. where is its documentation?

Sorry for the confusion. I'll submit it for formal review soon after receiving the initial feedback from the community and cleanup code and documents. Thanks for looking into it. Yigong

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

On 5/23/07, Scott Woods <scottw@qbik.com> wrote:

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?

Hello, Join calculus , as a process calculus, has been used for formal specification and validation of concurrent and distributed systems, including protocols. Its simple and well-defined core for concurrency (async / synch methods and join-patterns or chords) are well suited for programming and have been integrated with programming languages for real concurrent applications in two different ways: 1. Join's primitives are integrated into languages by changing compilers; such as JoCaml, Cw and Join.Java. 2. Join's primitives are added as a separate library; such as CCR, C#.Joins. The "Join" library i am proposing falls into this category. It is intended for implementing real concurrent applications. Its simple model of async / synch methods and join-patterns (chords) should give us guideline for concurrent design and help avoiding pitfalls. Thanks Yigong

Could join calculus compete with something like SDL? Is there a join-calculus- for-programmers reference?

Hello, You can find tutorial and references of join-calculus at its website : http://join.inria.fr/ I am not familiar with using Join in formal verification and model checking. Maybe you can find more by talking to people behind join-calculus: http://moscova.inria.fr/

From my prior exposure to Promela/Spin in a telecom switch project, it seems Spin has more tools for model extraction and verification (i guess it is same with SDL). Promela/Spin is more CSP-like while Join is a variant of async Pi calculus.

Regards, yigong