Lambda the Ultimate

Looking at the buffer example, Polyphonic C# would rendezvous the input and output as:

class Buffer { 
   string Get() & async Put(string s) { 
      return s;
   }
}

I gather from my intro book that the equivalent in Ada would be:

task BUFFERING is
   entry PUT(X: in STRING);
   entry GET(X: out STRING);
end;


task body BUFFERING is
   V: STRING;
begin
   loop
      accept PUT(X: in STRING) do
         V := X;
      end PUT;
      accept GET(X: out STRING) do
         X := V;
      end GET;
   end loop;
end BUFFERING;

I can see why the Ada solution would be much more flexible in the control over the process. But the Polyphonic C# does seem to have a certain attraction in it's simplicity. It also formally ties the two methods together formally - which I suppose could be used for some sort of static analysis.

Then again, my limited exposure to heavy use of threading, tasking, and distributed computing leans towards processes that are not one-to-one. The rendezvous usually involves waiting on a dynamic number of tasks - where a counting semaphore is more appropriate than a setEvent and getEvent combination.

That's what appealed to me too.

The problem is, I don't find the noatation easy to understand. For example, I am not sure if the Polyphonic C# example you give allows the sequence of operations Put, Put, Get? The Ada code you gave only alloaws (Put,Get)*.

One more thing. Ada tasks direclty communicate using rendezvous (which is one-to-one), but Ada also support protected objects which are extended monitors. These allow multile readers for example, and allow building various interesting and important synchronization objects (e.g., Brodcasts).

The problem is, I don't find the noatation easy to understand. For example, I am not sure if the Polyphonic C# example you give allows the sequence of operations Put, Put, Get? The Ada code you gave only alloaws (Put,Get)*.

async Put(string s) {
   Console.WriteLine("Hello Put");
}

The call to Put would return immediately and a new thread would be created that processed the Hello.

In the case of Chords, however, the call to Put will not generate a new thread process. It also won't process any of the commands within the defined method. It's like the Chord is little more than a buffer of messages (parameters) which are queued up against the sister method. Chords do not invoke a function nor do they create threads. From the original example,

string Get() & async Put(string s) { 
   Console.WriteLine("Hello Get");
}

In this example, you could call Put a gazillion times, and it will not result in hello. Only when Get is called will the Hello run (and then only if at least one Put was called). The Chord causes the Get function to wait on a Put operation, but the method is really only run when the Get method is invoked.

I suppose it might have been more obvious had the async keyword not been used in two different ways - perhaps calling the second one a chord.

One more thing. Ada tasks direclty communicate using rendezvous (which is one-to-one), but Ada also support protected objects which are extended monitors. These allow multile readers for example, and allow building various interesting and important synchronization objects (e.g., Brodcasts).