Databases
StackOverflow2013
Postsdbo
POManual threads vs Parallel.Foreach in task scheduler
 

Note that there are some explanatory texts on larger screens.

plurals
  1. POManual threads vs Parallel.Foreach in task scheduler
    primarykey
    data
    text
    <p>I have a Windows Service that processes tasks created by users. This Service runs on a server with 4 cores. The tasks mostly involve heavy database work (generating a report for example). The server also has a few other services running so I don't want to spin up too many threads (let's say a maximum of 4). </p> <p>If I use a <code>BlockingCollection&lt;MyCustomTask&gt;</code>, is it a better idea to create 4 Thread objects and use these to consume from the <code>BlockingCollection&lt;MyCustomTask&gt;</code> or should I use <code>Parallel.Foreach</code> to accomplish this? </p> <p>I'm looking at the <a href="http://blogs.msdn.com/b/pfxteam/archive/2010/04/06/9990420.aspx" rel="nofollow">ParallelExtensionsExtras</a> which contains a StaTaskScheduler which uses the former, like so (slightly modified the code for clarity):</p> <pre><code>var threads = Enumerable.Range(0, numberOfThreads).Select(i =&gt; { var thread = new Thread(() =&gt; { // Continually get the next task and try to execute it. // This will continue until the scheduler is disposed and no more tasks remain. foreach (var t in _tasks.GetConsumingEnumerable()) { TryExecuteTask(t); } }); thread.IsBackground = true; thread.SetApartmentState(ApartmentState.STA); return thread; }).ToList(); // Start all of the threads threads.ForEach(t =&gt; t.Start()); </code></pre> <p>However, there's also a <code>BlockingCollectionPartitioner</code> in the same <a href="http://blogs.msdn.com/b/pfxteam/archive/2010/04/06/9990420.aspx" rel="nofollow">ParallelExtensionsExtras</a> which would enable the use of <code>Parallel.Foreach</code> on a <code>BlockingCollection&lt;Task&gt;</code>, like so:</p> <pre><code> var blockingCollection = new BlockingCollection&lt;MyCustomTask&gt;(); Parallel.ForEach(blockingCollection.GetConsumingEnumerable(), task =&gt; { task.DoSomething(); }); </code></pre> <p>It's my understanding that the latter leverages the <code>ThreadPool</code>. Would using Parallel.ForEach have any benefits in this case?</p>
    singulars
    1. PO
      singulars
      1. PTAnswer
    1. This table or related slice is empty.
    1. PTQuestion
    1. USdiggingforfire
    1. USdiggingforfire
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. PO
      singulars
      1. PTAnswer
    1. VO
      singulars
      1. POManual threads vs Parallel.Foreach in task scheduler
      1. This table or related slice is empty.
      1. VTUpMod
    2. VO
      singulars
      1. POManual threads vs Parallel.Foreach in task scheduler
      1. USsvick
      1. VTFavorite
    1. COWhat you have written doesn't make much sense. Tasks and Parallel.ForEach are based on Threads. So, you run threads to run tasks (e.g. run more threads). This solution will not help you with performance.
      singulars
      1. POManual threads vs Parallel.Foreach in task scheduler
      1. USevhen14
    2. COThe Task is a custom made class (i.e. not System.Threading.Tasks.Task). I've edited the question to make it more clear.
      singulars
      1. POManual threads vs Parallel.Foreach in task scheduler
      1. USdiggingforfire
    3. COthe TPL will opt to perform them in sequence and not in parallel if it determines that a set of tasks would gain little or no benefit by running in parallel.And yes it leverages the ThreadPool and manage concurrency on your behalf
      singulars
      1. POManual threads vs Parallel.Foreach in task scheduler
      1. USterrybozzio
 

Querying!

 
Guidance
A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload