title: TPL architectural question
body: <p>I'm currently working on a project, where we have the challenge to process items in parallel. So far not a big deal ;)
  Now to the problem. We have a list of IDs, where we periodically (every 2 sec's) what to call a StoredProcedure for each ID.
  The 2 sec's need to be checked for each item individually, as they are added and removing during runtime.
  In addition we want to configure the maximum degree of parallelism, as the DB should not be flooded with 300 threads concurrently.
  An item which is being processed should not be rescheduled for processing until it has finished with the previous execution. Reason is that we want to prevent queueing up a lot of items, in case of delays on the DB.</p>
  
  <p>Right now we are using a self-developed component, that has a main thread, which periodically checks what items need to scheduled for processing. Once it has the list, it's dropping those on a custom IOCP-based thread pool, and then uses waithandles to wait for the items being processed. Then the next iteration starts. IOCP because of the work-stealing it provides.</p>
  
  <p>I would like to replace this custom implementation with a TPL/.NET 4 version, and I would like to know how you would solve it (ideally simple and nicely readable/maintainable).
  I know about this article: <a href="http://msdn.microsoft.com/en-us/library/ee789351.aspx">http://msdn.microsoft.com/en-us/library/ee789351.aspx</a>, but it's just limiting the amount of threads being used. Leaves work stealing, periodically executing the items ....</p>
  
  <p>Ideally it will become a generic component, that can be used for some all the tasks that need to be done periodically for a list of items.</p>
  
  <p>any input welcome,
  tia
  Martin</p>