I'm sorry Dave, I'm afraid I can't do that.

Actually, we've covered Joins already. I just forgot to mention it. The MultipleItemReceives we covered in Part 4 are joins, i.e. they wait for all the ports to produce n messages. All Joins (like their name suggests) are just rendezvous points for a set of messages and are an important construct - without them, we wouldn't easily be able to gather the results of a parallelized operation.

Whilst the most useful arbiters are typically those that allow you to deal with a concurrency problem whose size isn't known until runtime, there exists a join across two ports that is explicitly provided for by the Arbiter class (not unlike Choice in fact). The following sample takes a number, n, and a string from the console and prints that string n times.

class Sample0601 {
    static void Main(string[] args) {
        using (DispatcherQueue dq = new DispatcherQueue()) {
            Port<int> intPort = new Port<int>();
            Port<string> stringPort = new Port<string>();
            Arbiter.Activate(dq, Arbiter.JoinedReceive(false, intPort, stringPort, 
                delegate(int n, string s) {
                    for (int i = 0; i < n; ++i) {
                        Console.WriteLine(s);
                    }
                }));
            Console.Write("Enter a number: ");
            intPort.Post(Int32.Parse(Console.ReadLine()));
            Console.Write("Enter a phrase: ");
            stringPort.Post(Console.ReadLine());
            Console.ReadLine();
        }
    }
}

In the next post, I'll introduce the final arbitration, Interleave. Conceptually, its a message-passing version of the Reader-Writer lock, scheduling readers and writers in a way that balances concurrency with correctness, albeit in an asynchronous fashion. Nearly every resource with some modifiable state can be protected by an Interleave and indeed it forms a core component of every service in the DSS.

Once the section on Arbitrations is complete, I want to cover the following (in order).

1. Dispatchers. So far we've only really looked at DispatcherQueues running across the CLR thread-pool. By using our own Dispatchers we can control the number of threads and various properties of those threads (such as COM Apartment type).


2. Iterative Tasks. Hugely important to the CCR, IterativeTasks exploit C# 2.0 iterator functionality to allow logical sequences of asynchronous methods to be written without ever blocking a physical thread.


3. Causalities. A cross-thread extension of exceptions, they allow errors raised in some scheduled task, to propagate through their causalities, back to the instigator of the operation.

Longer term, I'll be posting some useful samples of code, illustrating usage with asynchronous sockets, asynchronous database interaction, interoperability with COM and UI threads and how the CCR can power your WCF-enabled server (or async ASP.NET web pages). If you have any specific requests, please leave them in the comments section.