Activate() is really a form of "spawn" or "execute in parallel"

Hi, we actually *never*, ever, block a thread outside the internals of the scheduler. All we do, which you correctly assumed, is enqueue Tasks (and Arbiters, like Interleave, Receiver, etc are all derived from) on dispatcher queues!. The CCR has actually avery simple design: Everything is a task. Dispatcher queues queue tasks, dispatchers schedule them across N threads.

The CCR User guide clarifies all these points, please let me know if it does not

George,

Thanks for clearing that up. Only a Dispatcher will ever schedule a task which will cause a delegate to execute on some Thread (more than likely a different thread). Only Activate() associates the arbiter to a DispatcherQueue. Therefore each time you create one of the arbiter objects, you would need to wrap it in an Activate method.

The only exception is inside an Iterator:

    void StartIterator()
    {
      // create an IterativeTask instance and schedule it
      Arbiter.Activate(_taskQueue,
        Arbiter.FromIteratorHandler(IteratorExample)
      );
    }
    /// <summary>
    /// Iterator method scheduled by the CCR
    /// </summary>
    IEnumerator<ITask> IteratorExample()
    {
      // accumulator variable
      int totalSum = 0;
      Port<int> portInt = new PortSet<int>();      
      // using CCR iterators we can write traditional loops
      // and still yield to asynchronous I/O !
      for (int i = 0; i < 10; i++)
      {
        // post current iteration value to a port
        portInt.Post(i);
        // yield until a delegate executes in some other thread 
        yield return Arbiter.Receive<int>(false, portInt, delegate(int j)
        {
          // this delegate can modify a stack variable, allowing it
          // communicate the result back to the iterator method
          totalSum += j;
        });
      }
      Console.WriteLine("Total:" + totalSum);
    }

In this case we see "yield return Arbiter.Receive ...". Does this mean the yield return implicitly does the same thing as Arbiter.Activate

Thanks,

Dogulas

George,

I'm sure it has to do with this passage that I found in the CCR User Guide, CCR Iterators, near the bottom of Example 18.

I thought the Dispatcher class did the scheduling. Is this CCR scheduler some kind of singleton object that the Dispatcher hands things off to Does this mean the yield return bypasses a Dispatcher and goes directly to this CCR scheduler

Thanks,

Dogulas

Rob,

Hey, thanks for the reply! I was aware of the blocking behavior of yield return and the problems I would incur in a truely parallel environment.

The question I really had was the underlying mechanism. I understand that Arbiter.Recieve() returns an arbiter class which is a type of task. By itself, it doesn't do anything and must be "scheduled". In all other examples of arbiter class creation, the resulting arbiter is passed to Arbiter.Activate() so that a Dispatcher can schedule it on some thread.

What happens behind the scenes when you yield return on a simple arbiter class I know it blocks, but how does it get scheduled Does it go through a Distributer behind the scenes How does the "CCR scheduler" mentioned in the documentation relate to a Distributer

Dogulas

Ok. I'm going to take a stab at this. Please feel free to shoot holes in it.

Dogulas

An iterator is a section of code that returns an ordered sequence of values of the same type. The way iterators are used in CCR is as the body of a method and the value returned is of type ITask.

When calling an iterator block you are asking it to return those values one at a time. Typically you would process each returned value with a foreach statement. If the iterator block were a method named ※GetEnumerator()§, you could use the object name directly.

Douglas hi,

My understanding is that the iterator functionality does *not* block - it simply defers calling MoveNext() until the yielded task (be that an arbitration or whatever) has fully completed. This has the effect of logically pausing the execution of the method, without *ever* blocking (or pausing) the thread.

Once the yielded task has been prepared, the thread will mostly likely go off and do something else, i.e. you could in principle get a different thread executing between each yield in your iterator method.

<shamelessplug>

I blogged about this a month or so ago, if it helps.

</shamelessplug>

Nick.

Hi i cant really disclose how we do iterator scheduling. Its actually not that complicated and the CCR guide (which you quoted earlier) explains what happens.

Again, we only "logically" block your iterator method, no thread is blocked. This allows you to have millions of pending iterators, waiting on I/O....

Thanks guys,

Nick, that is a great writeup in your blog. Very clear and consise. It helped a lot. By the way, the name is Dogulas. The bank screwed up the spelling, but I liked it so I kept it. ;-}

George, Thanks for clearing up the terminology. I'm just going to trust you on this non-blocking-deferred-calling secret thingy that you do.

I did a little test to see what code was ending up on which thread and was quite surprised by the results. I'll include the code at the bottom so you won't have to wade through it if you don't want to. Appearantly there is some magic in the FromIteratorHandler method. I would have guessed the iterator processing would be dealt with on the main thread and only the scheduling of the delegates would be shifted to the threads managed by the Distributor. Instead, the FromIteratorHandler method returns almost immediately and any code in the iterator method as well as the scheduled delegates seems to be placed randomly on the Distributer managed threads. Furthermore, code before and after a yield return statement may easily end up on different threads.

True to your word, however, all the code in the iterator method including the delegates function in a top down manner, regardless of the threads they are on. The following code sample would return:

Main Thread: 9

finished Main Thread: 9

Iterator Thread: 11

DelegateA Thread: 11

Iterator Thread: 11

DelegateB Thread: 12

Iterator Thread: 12

DelegateC Thread: 12

Iterator Thread: 12

Over several runs the iterator threads and the delegate threads are alway some random combination of 11 and 12. If I comment out the line "portB.Post(2);" so that portB is empty, then the "DelegateB Thread" line and all following lines are never printed. I guess I was surprised that the iterator code was also being scheduled. That may not be technically correct, but it seems as if it is being scheduled.

Here is the code:

The CCR (and me) does not want its users to think about threads. The CCR user guide should be more explicit but unless you want tight thread affinity for legacy interop reasons, always assume tasks, including tasks you yield to from an iterator will run on *arbitrary* thread context. You should basically not care what thread executes your task.

The CCR dispatcher will load balance as it sees fit to maximize CPU utilization across all cores/processors.

Your example only ever has one task running so the CCR picks up an available thread at random (its a pure race between threads).

thanx

g