multithreading - What's the operational difference between Parallel and Task in C#? -

i work sole application developer within database-focussed team. recently, i've been trying improve efficiency of process predecessor had prototyped. best way thread it. approach:

public void dosomething() {     parallel.foreach(rowcollection), (fr) =>     {         fr.result = mycleaningoperation();     }); } 

which functions fine, causes errors. errors arising in third-party tool call coding. tool supposed thread safe, looks though they're arising when 2 threads try , perform same operation @ same time.

so went prototype. i'd looked @ see how talk third-party tool. when examined called code, discovered predecessor had threaded using task , action, operators i'm not familiar.

action<object> mycleaningoperation = (object obj) => {     // invoke third-party tool. }  public void main() {     task[] taskcollection = new task[1];     (int = 0; < rowcollection.length; i++)     {         taskcollection[i] = new task(mycleaningoperation, i);     }      foreach (var task in taskcollection)     {         task.start();     }      try     {         task.waitall(taskcollection);     }     catch (exception ex)     {         throw ex;     } } 

now, that's not great code prototype. allegedly prototype did not error , ran @ greater speed mine. cannot verify because prototype dependent on dev database no longer exists.

i don't particularly want go on wild goose chase of trying out different kinds of threading in app see if throw errors or not - they're intermittent long drawn out process. more because having read task cannot see reason why work more parallel. , because i'm using void function cannot add await mimic prototype operation.

so: there operational difference between two? or other reason why 1 might cause tool trip multiple threads using same resource , other not?

action<t> void-returning delegate takes t. represents operation consumes t, produces nothing, , started when invoked.

task<t> says on tin: represents job possibly not yet complete, , when complete, provides t completion.

so, let's make sure you've got far: what completion of task<t>?

don't read on until you've sussed out.

.

.

.

.

.

the completion of task action. task produces t in future; action performs action on t when available.

all right, task, no t? task not produce value when completes. what's completion of task? plainly action.

how can describe task performed task then? produces no result. that's action. suppose task requires consumes object work; that's action<object>.

make sure understand relationships here. bit tricky make sense. names chosen.

so thread? a thread worker can tasks. do not confuse tasks threads.

having read task cannot see reason why work more parallel.

you see mean hope. sentence makes no sense. tasks that: tasks. deliver book address. add these numbers. mow lawn. tasks not workers, , not concept of "hire bunch of workers tasks". parallelism strategy assigning workers tasks.

moreover, not fall trap of believing tasks inherently parallel. there no requirement tasks performed simultaneously multiple workers; of work we've done in c# in past few years has been ensure tasks may performed efficiently single worker. if need make breakfast, mow lawn , pick mail, don't need hire staff things, can still pick mail while toast toasting.

you should examine claim best way increase performance parallelize. remember, parallelization hiring many workers there cpu cores run them, , handing out tasks each. improvement if (1) tasks can run in parallel, independently, (2) tasks gated on cpu, not i/o, , (3) can write programs correct in face of multiple threads of execution in same program.

if tasks "embarrassingly parallel" , can run completely independently of each other might consider process parallelism rather thread parallelism. it's safer , easier.