Michael Garski

Within our search infrastructure we use the CCR to manage concurrency in our processing pipeline to assign indexing tasks to a pool of workers.  The benefits we've receieved from using the CCR are that it simplifies concurrency management and provides a very high level of throughput.  At this time we are not currently using the CCR during search execution but are examining ways in which we can.

georgioc wrote:



mgarski wrote:George, I've become a big fan and evangelist of the CCR and have been experimenting with it in a few Windows services I maintain.  I do have a few questions for you as to it's use in my scenarios. First of all, every Arbiter I use is persistent and when the service recieves a shutdown signal I want to cancel all pending tasks.  I have found that by calling Dispose on the DispatcherQueue instances I can clear out the tasks that have not yet started while allowing those currently running to continue.  Would you consider this approach a safe way of cancelling pending/queued tasks? Secondly, all of the work performed by the threads in my application require access to a shared resource and I need to ensure that all of the work is complete before I close up the resource and exit the application.  I've experimented with the DispatcherQueue.Count and Dispatcher.PendingTasks properties but have found that they are both decremented when a task begins to run, and the Dispatcher.ProcessedTasks property is also incremented at that time.  I've taken to the approach of having a property that reflects the current state of the object that is running on the CCR thread to ensure it is complete such as: while(!AllWorkComplete()) {     Thread.Sleep(100); } CloseSharedResource(); Where all work complete iterates through the objects that are performing the work and return false if any one is still running.  This is working in my application but I was wondering why there is not a "RunningTasks" property on the Dispatcher similar to PendingTasks and ProcessedTasks. The CCR has made my life so much easier and my code far cleaner and easier to maintain - especially using Interleave for concurrent and exclusive tasks. Thanks, Mike

Glad to hear its working well. On your questions:

1) Per service, assuming it has an interleave around its persistent receivers, i would recommend having a one time receiver in a teradown group, to do any cleanup . This guarantees teardown will happen after all receivers for that service have stopped executing, and no more will ever run after. What you use now is more appropriate for process wide, cleanup

2) Also here, interleave takes care of this since it exactly tracks internally what receivers are running. Then , if you use the teardown group, when you decide to shutdown, your shutdown will only run when all active tasks generated from within the interleave, have stopped.

If its not feasible to use interleave or you want to make sure that everything is done across multiple interleaves or other arbiters, all associated with one dispatcher, then your approach is fine.
We don have a running tasks value since its almost alwasy guaranteed to be out of sync and will force even more memory coherence between workers, slowing down perf. We try to keep the dispacther workers independent of each other, so they can run at maximum concurrency. Note that the max number of active tasks will always be equal to the thread workers, never more. So if the queue counts for the dispatcher queues are < Worker count, that means things are about to idle.

g

George -

Thanks for your answer, I am currently using an interleave and will add a TeardownReceiverGroup that will get an object posted to it on the service's shutdown signal.

Given that, I'm assuming that if I want to ensure that all of the messages on the dispatcher queue are processed I would want to do something like:

while(dispatcherQueue.Count > 0)
{
    Thread.Sleep(100);
}

shutdownPort.Post(new Object());

I think this would safely let all of the queued up tasks to process and then post to my shutdown port firing off the TeardownReceiverGroup to perform any final cleanup necessary, correct?

Thanks again,

Mike

George,

I've become a big fan and evangelist of the CCR and have been experimenting with it in a few Windows services I maintain.  I do have a few questions for you as to it's use in my scenarios.

First of all, every Arbiter I use is persistent and when the service recieves a shutdown signal I want to cancel all pending tasks.  I have found that by calling Dispose on the DispatcherQueue instances I can clear out the tasks that have not yet started while allowing those currently running to continue.  Would you consider this approach a safe way of cancelling pending/queued tasks?

Secondly, all of the work performed by the threads in my application require access to a shared resource and I need to ensure that all of the work is complete before I close up the resource and exit the application.  I've experimented with the DispatcherQueue.Count and Dispatcher.PendingTasks properties but have found that they are both decremented when a task begins to run, and the Dispatcher.ProcessedTasks property is also incremented at that time.  I've taken to the approach of having a property that reflects the current state of the object that is running on the CCR thread to ensure it is complete such as:

while(!AllWorkComplete())
{
    Thread.Sleep(100);
}

CloseSharedResource();

Where all work complete iterates through the objects that are performing the work and return false if any one is still running.  This is working in my application but I was wondering why there is not a "RunningTasks" property on the Dispatcher similar to PendingTasks and ProcessedTasks.

The CCR has made my life so much easier and my code far cleaner and easier to maintain - especially using Interleave for concurrent and exclusive tasks.

Thanks,

Mike