Implementing 'only one of' and 'not in parallel' semantics with the Task parallel library

Question

What would be the best approach for implementing Tasks with a KEY that operate as follows:-

Option 1) Only one of this key is ever pending. Can be used, for example, from ASP.NET MVC to queue up a single render for a thumbnail image no matter how many times the image Url is hit. Only one runs, all other requests wait for that one to complete.

Option 2) All items with the same key must execute sequentially. Can be used for example to ensure that operations that fetch a file from a backing store to a local cache don't all try to get the file to the cache at the same time. Option 1 is a special case of this where subsequent actions with the same key are simply discarded (typically saves just a file-exists-check).

I have an existing WorkQueue that handles both of these cases (as well as Apartment state, ThreadPriority settings and maximum degrees of parallelism). TPL appears to be the best solution for replacing this and will bring improved cancellation options.

Nested Tasks with continuations look hopeful but maintaining a dictionary of currently queue'd tasks soon gets messy between the TaskFactory and the TaskScheduler classes. Inheriting from Task is problematic too since neither TaskFactory nor TaskScheduler are generic on Task.

Most Task Parallel examples assume that the set of tasks is known ahead of time. In this case new tasks are added all the time and need to be either discarded or chained onto existing tasks depending on the operation requested and the key passed in.

Has anyone implemented anything similar to this using TPL and if so, what approach did you take in your Task, TaskScheduler and TaskFactory classes?

Answer 1

This problem is similar to one I solved in ReactiveXaml, though mine also memoized previous requests. Take a look at the code for QueuedAsyncMRUCache (and its blog entry) - this code combines the TPL with the Reactive Extensions to get this kind of thing done, but it makes the important guarantee that the 2nd request for the same key will block on the first in-flight request instead of issuing another one.

Answer 2

Perhaps, one way that I can think of is

1. Create a wrapper class - say KeyProcessor to queue up items for a key.
2. KeyProcessor.Run() method will be capable of whatever queuing semantics that you need for. Essentially it would look for internal queue for any pending work and then keep doing it sequentially.
3. Maintain the dictionary of KeyProcessor objects.
4. For any new task, check in the dictionary for the same key. If does not exist then add it. Queue the task on it. If its not running then schedule it with TPL using Run method as action.
5. Use ContinueWith to schedule maintainer task - for example, whenever Task executing KeyProcessor.Run is completed, continuation tasks can check if there are any more tasks been scheduled for the same key (since it has completed) and start it again OR remove from dictionary.

All above would have been tricky from thread sync point not for few interesting collections present in System.Collections.Concurrent namespace. This would make the above logic much more simpler. For example, ConcurrentDictionary.GetOrAdd will allow to lookup and/or add the KeyProcessor object in thread-safe way.