c# - Need a queue of jobs to be processed by threads -

i have work (a job) in queue (so there several of them) , want each job processed thread.

i looking @ rx not wanted , came across parallel task library.

since work done in web application not want client waiting each job finished, have done following:

    public void fromwebclientrequest(int[] ids);     {         // objects ids repository using container (unity)          threadpool.queueuserworkitem(delegate                                          {                                              dosomeworkinparallel(ids, container);                                          });     }      private static void dosomeworkinparallel(int[] ids, container)     {         parallel.foreach(ids, id=>                                         {                                             work done here...                                             var respository = container.resolve...                                         });          // here work done.        container.resolve<ilogger>().log("finished work");     } 

i call above code on web request , client not have wait.

is correct way this?

tia

from msdn docs see unitys icontainer resolve method not thread safe (or not written). mean need out of thread loop. edit: changed task.

public void fromwebclientrequest(int[] ids); {    irepotype repotype = container.resolve<irepotype>();    ilogger logger = container.resolve<ilogger>();    // remove longrunning if operations not blocking (ie. read file or download file  long running queries etc)    // prefer fairness here try complete first requests came first, client more able served "first come, first served" in case of high cpu use lot of requests    task.factory.startnew(() => dosomeworkinparallel(ids, repotype, logger), taskcreationoptions.longrunning | taskcreationoptions.preferfairness); }  private static void dosomeworkinparallel(int[] ids, irepotype repository, ilogger logger) {     // if there blocking operations inside loop ought convert tasks longrunning     // why this? force more threads used run loop, , try saturate cpu use, doing nothing of time     // beware of doing if work on non clustered database, since can saturate , have bottleneck there, should try , see how handles workload     parallel.foreach(ids, id=>{                   // work done here...                   // use repository              });    logger.log("finished work"); } 

plus fiver stated, if have .net 4 tasks way go.

why go task (question in comment):

if method fromclientrequest fired insanely often, fill thread pool, , overall system performance not .net 4 fine graining. task enters game. each task not own thread new .net 4 thread pool creates enough threads maximize performance on system, , not need bother on how many cpus , how thread context switches there be.

some msdn quotes threadpool:

when thread pool threads have been assigned tasks, thread pool not begin creating new idle threads. avoid unnecessarily allocating stack space threads, creates new idle threads @ intervals. interval half second, although change in future versions of .net framework.

the thread pool has default size of 250 worker threads per available processor

unnecessarily increasing number of idle threads can cause performance problems. stack space must allocated each thread. if many tasks start @ same time, of them might appear slow. finding right balance performance-tuning issue.

by using tasks discard issues.

another thing can fine grain type of operation run. important if tasks run blocking operations. case more threads allocated concurrently since wait. threadpool cannot achieve automagically:

task.factory.startnew(() => dosomework(), taskcreationoptions.longrunning); 

and of course able make finish on demand without resorting manualresetevent:

var task = task.factory.startnew(() => dosomework()); task.wait(); 

beside don't have change parallel.foreach if don't expect exceptions or blocking, since part of .net 4 task parallel library, , (often) works , optimized on .net 4 pool tasks do.

however if go tasks instead of parallel for, remove longrunning caller task, since parallel.for blocking operations , starting tasks (with fiver loop) not. way loose kinda first-come-first-served optimization, or have on lot more tasks (all spawned through ids) give less correct behaviour. option wait on tasks @ end of dosomeworkinparallel.