What is the difference between a Task and a Thread, what is the Task Parallel Library, and when do you use Parallel.ForEach?

Say it out loud, then check

One valuation run, every idea

The BMW FS month-end run, in time order: an awaited Task for the load, pool threads for the CPU work, and Parallel.ForEach to split the list.

The story

1. Before

   A residual value is the predicted worth of a car at the end of its lease, the rental contract BMW FS signs with a dealer's customer. The risk team revalues every open lease once a month. The job was one foreach loop: 240,000 leases, one after another on one thread (one worker the operating system runs). Each value was a small calculation over the lease's age, miles and model. The run took 3 hours 40 minutes, started at 02:00 ET, and had to finish before the dealer feed at 05:30 ET, the file that sends each dealer their book value.

   Valuation job240,000 leases

   One threadone lease at a time

   1/2Before: one thread values 240,000 leases, one lease after another.It ends at 05:40, ten minutes late. The feed sends yesterday's values.

   BackPlayNext
2. Why it had to change

   Parallel.ForEach is the data-parallel loop of the TPL (Task Parallel Library), .NET's set of tools built on a Task, a promise of work that finishes later. The loop takes a collection, splits it into ranges (chunks of the list, one per thread), and asks the thread pool (the team of reusable worker threads .NET keeps) to run the body (the code inside the loop) on several threads at once. It is synchronous: the calling thread waits until every range is done. That is right for CPU-bound work (maths the processor must do) and wrong for I/O-bound work (waiting on SQL, HTTP or a file), where you should await a Task: await waits for it without blocking the thread. It is also unsafe when every iteration writes to one shared object.

3. How it works now

   The fix had three rules. First, the body is pure (it reads its input and returns a result without touching shared state): a method reads one lease and returns one number. Second, results go into an array sized before the loop, and each iteration writes its own index; two threads never touch the same slot, so no lock is needed (a lock lets one thread at a time run a block). Third, the database stays out of the parallel loop: one DbContext (the database object from Entity Framework Core, .NET's database library; it is not thread-safe, meaning many threads cannot use it at once without losing data) saves the finished array in batches afterwards. MaxDegreeOfParallelism, the setting that caps how many iterations run at once, keeps one core free for the API.

   Valuation jobone run

   Thread poolreused workers

   Results arrayone slot each

   Azure SQLone writer

   240,000 leases

   1/5The job splits 240,000 leases into ranges and hands them to the thread pool.Pool threads take ranges. Each runs the pure value method: no shared object.Lease i writes values[i]. Two threads never write the same slot, so no lock.The loop waits for every range, then one thread saves the full array.At 05:30 the feed reads today's values: 38 minutes, not 3 hours 40.

   BackPlayNext
4. What we gained

   Once you know which tool owns the work, the choice is quick: await a Task for waiting, split CPU work with the TPL, and keep every shared object out of the parallel body. The rest of the card shows the code, the two run-time bugs that cost us a night, the interview follow-ups, and three live tasks.

In the lending API

Three tests, three tools. Each marked line is one of them; "See it" shows where the work runs.

Only the key lines are shown; Deep walks the whole file.

The code, file by file

Three xUnit tests (xUnit is a .NET test tool) that show a Task, a Thread and a Parallel.ForEach side by side. Tap Next to walk the diagram with the code.

What they ask next

The follow-ups interviews really ask. Answer out loud, then tap to check.

• ReportedWhat is the difference between a Task and a Thread?

  A Thread is an OS-level worker: you create it, it has its own stack, and it runs until its method returns. A Task is a promise for work that finishes later. It does not own a thread: an async I/O Task waits with no thread, and a CPU-bound Task runs on a thread-pool thread. A Task also carries a result, an exception and cancellation, and you can await it or combine it with Task.WhenAll. In a web app I use Tasks and the pool, not a new Thread per request.

  // Work and CalcAsync are your own methods
  Thread t = new Thread(Work);
  t.Start();
   
  Task<int> task = CalcAsync();
  int value = await task;

  Next questions, in Deep →MPRDC: what is a thread in C#
• ReportedWhat is the Task Parallel Library?

  The TPL is the set of types in System.Threading.Tasks that model work: Task and Task<T>, Task.Run, Task.WhenAll, continuations (the code after an await), cancellation with CancellationToken, and the data-parallel loops Parallel.For and Parallel.ForEach. It schedules work on the thread pool, carries results and exceptions, and lets the runtime decide how many threads to use. Before it, we created threads and waited on them by hand; the TPL replaced that with tasks.

  Next questions, in Deep →Celebal Technologies: explain the TPL
• ReportedWhat is the difference between a foreach loop and Parallel.ForEach?

  A foreach runs the body once at a time on the calling thread, in order. Parallel.ForEach splits the collection into ranges and runs the body on several thread-pool threads at once. It is synchronous: it returns only when every range is done. The order is not preserved, the body must be thread-safe, and exceptions come back together in an AggregateException. It helps only when the body is CPU-bound and big enough to pay the splitting cost. For SQL or HTTP calls, use async with Task.WhenAll or Parallel.ForEachAsync.

  foreach (var row in rows)
  {
    Work(row);
  }
   
  Parallel.ForEach(rows, row =>
  {
    Work(row);
  });

  Next questions, in Deep →UST: foreach vs Parallel.ForEach

Follow-up tree

Answer, then open the next level. That is the order an interviewer digs in.

Reporteda candidate was asked Intervieweran interviewer asks it

• ReportedWhat is the difference between a Task and a Thread?

  A Thread is an OS-level worker: you create it, it has its own stack, and it runs until its method returns. A Task is a promise for work that finishes later. It does not own a thread: an async I/O Task waits with no thread, and a CPU-bound Task runs on a thread-pool thread. A Task also carries a result, an exception and cancellation, and you can await it or combine it with Task.WhenAll. In a web app I use Tasks and the pool, not a new Thread per request.

  // Work and CalcAsync are your own methods
  Thread t = new Thread(Work);
  t.Start();
   
  Task<int> task = CalcAsync();
  int value = await task;

  MPRDC: what is a thread in C#
  • Would you ever create a Thread yourself?

    Only for a long-running dedicated loop that must not compete with pool work, and then with IsBackground = true so it does not keep the app alive. For a normal request or a short job, Task.Run or Parallel is the better tool.

  • Is a Task always running on a thread?

    No. A Task from an async I/O call waits on the OS; no thread is busy. A Task from Task.Run does occupy a pool thread while its code runs.

• ReportedWhat is the Task Parallel Library?

  The TPL is the set of types in System.Threading.Tasks that model work: Task and Task<T>, Task.Run, Task.WhenAll, continuations (the code after an await), cancellation with CancellationToken, and the data-parallel loops Parallel.For and Parallel.ForEach. It schedules work on the thread pool, carries results and exceptions, and lets the runtime decide how many threads to use. Before it, we created threads and waited on them by hand; the TPL replaced that with tasks.

  Celebal Technologies: explain the TPL
  • Task, Thread and ThreadPool: how do they relate?

    The ThreadPool is the set of reusable worker threads. A Thread is one worker you create yourself. A Task is a unit of work that the TPL schedules, usually on the pool. Most modern .NET code uses Tasks and leaves the pool alone.

  • What does Task.Run do?

    It queues a delegate to the thread pool and returns a Task for it. Use it for CPU-bound work that would block the current thread. It does not make I/O faster; for I/O, call the async API directly.

• ReportedWhat is the difference between a foreach loop and Parallel.ForEach?

  A foreach runs the body once at a time on the calling thread, in order. Parallel.ForEach splits the collection into ranges and runs the body on several thread-pool threads at once. It is synchronous: it returns only when every range is done. The order is not preserved, the body must be thread-safe, and exceptions come back together in an AggregateException. It helps only when the body is CPU-bound and big enough to pay the splitting cost. For SQL or HTTP calls, use async with Task.WhenAll or Parallel.ForEachAsync.

  foreach (var row in rows)
  {
    Work(row);
  }
   
  Parallel.ForEach(rows, row =>
  {
    Work(row);
  });

  UST: foreach vs Parallel.ForEach
  • When is Parallel.ForEach slower?

    When the collection is small, the body is tiny, or every iteration takes the same lock. Splitting and synchronising cost more than the work saves. I measure with a Stopwatch on the real collection before changing a loop.

  • How do you stop a parallel loop early?

    The body receives a ParallelLoopState (the object passed to the body, with Break and Stop) and can call Break (finish the iterations with lower indices) or Stop (end as soon as it can). The returned ParallelLoopResult (the loop's completion report) tells you whether it completed and where it stopped.

  • How do you limit how many run at once?

    ParallelOptions.MaxDegreeOfParallelism. I set it to one fewer than the processor count when the API shares the machine, and to a small number like 8 for I/O calls, so the database is not flooded.

• ReportedWhat is the difference between concurrency and parallelism?

  Concurrency is handling several things in overlapping time; parallelism is running them at the same instant on different cores. Async I/O is concurrency without parallelism: one thread starts 100 HTTP calls and awaits them, and no thread is busy while they wait. Parallel.ForEach is parallelism: several threads compute at once. A single-core machine can be concurrent but not parallel.

  // concurrency: one thread, many waits
  Task a = api.GetAsync(1);
  Task b = api.GetAsync(2);
  await Task.WhenAll(a, b);
   
  // parallelism: many cores compute
  var fees = new ConcurrentBag<decimal>();
  Parallel.ForEach(rows, row =>
    fees.Add(Cost(row)));

• Does async/await create a new thread?

  No. async marks a method that can wait; await frees the current thread while the I/O is pending. When the answer arrives, a thread from the pool continues the method. For CPU-bound work, await alone does nothing; Task.Run moves that work to a pool thread.

  The async/await card →
• Why not create a new Thread for every request?

  Each thread reserves its own stack and costs the OS time to create and switch (that save-and-load is a context switch: the OS saves one thread's place and loads another's). A busy API with 500 requests would create 500 threads instead of reusing a small pool; memory and context switching explode. ASP.NET Core already runs each request on a pool thread; for waiting, async frees that thread; for CPU work, Task.Run queues to the same pool.

  • What is thread pool starvation?

    The pool has a limited number of threads and grows slowly. If request threads block on .Result or .Wait() (both block the thread until the Task ends) or a long synchronous call, the pool runs out and new requests queue. Latency climbs even though the CPU is idle. The fix is async all the way, not more threads.

• ReportedHow do you handle exceptions in Parallel.ForEach?

  Any exception from a body is caught by the loop; it stops starting new iterations, lets the running ones finish, then throws one AggregateException, and InnerExceptions holds every failure. I catch it, log each inner exception with the lease id, and decide whether the batch can be retried. Parallel.ForEachAsync is different: the await rethrows only the first failure, so if I need every failure I keep the Task and read task.Exception.InnerExceptions, or catch inside the body and collect them.

  try
  {
    Parallel.ForEach(rows, Work);
  }
  catch (AggregateException ex)
  {
    foreach (var inner in ex.InnerExceptions)
    {
      log.LogError(inner, "row failed");
    }
  }

• ReportedCan a DbContext be used inside Parallel.ForEach?

  No. A DbContext is not thread-safe and tracks one unit of work. Parallel bodies would share it and throw "A second operation was started on this context instance before a previous operation completed." I load the rows first, do the CPU work in parallel with no context, then save once; or I create one context per iteration with a factory (IDbContextFactory<T>, which makes a fresh context on each call).

  List<Lease> leases =
    await context.Leases.ToListAsync();
   
  // CPU work only: no DbContext here
  Parallel.ForEach(leases, lease =>
    Value(lease));

• What about Parallel.ForEachAsync?

  It is the async version, added in .NET 6. The body is async, the loop awaits every call, and MaxDegreeOfParallelism limits how many are in flight. Use it for many independent I/O calls, not for CPU work. The await rethrows only the first failure; to get them all, keep the Task and read task.Exception.InnerExceptions, or catch inside the body and collect them.

  await Parallel.ForEachAsync(ids,
    new ParallelOptions
    {
      MaxDegreeOfParallelism = 8
    },
    async (id, ct) =>
    {
      await api.GetAsync(id, ct);
    });

• How would you test parallel code?

  Run it many times with a count and a checksum, not once. Assert that every input produced exactly one result, that the total matches the sequential version, and that no result is null. To expose a race, add a test-only delay inside the body to widen the window, or run a stress loop. A single green run proves very little.

  for (int run = 0; run < 20; run++)
  {
    var values = Job.ValueAll(leases);
    Assert.Equal(10_000, values.Length);
    Assert.All(values, v =>
      Assert.NotNull(v));
  }

Production bugs, and how to tell them

Each one: what you see, why, the fix in code, and the line to say.

• Parallel.ForEach lost 3,200 valuations

  BMW FS risk report, first night after release 4.2:
  "Open leases: 240,000. Valued this month: 236,800."
  (no exception in the job log on that run)

  Cause

  The body added to one List<Valuation>. A List is not thread-safe: two threads can read the same internal size, both write to the same slot, and one add is lost. When the list grows, two threads can also resize the same hidden array; on a different night that threw ArgumentException: Source array was not long enough inside an AggregateException.

  Fix

  Size a Valuation[] before the loop and let each iteration write its own index. No two threads write the same slot, so no lock is needed. Sum and save after the loop, on one thread. A test runs 10,000 leases and asserts that every slot has a value.

  BeforeValuationJobTests.csAfter

  1var values = new List<Valuation>();2Parallel.ForEach(leases, lease =>3{4 values.Add(Value(lease));5});6await repository.SaveAsync(values);

  Before · ValuationJob.cs · line 1 · 1 of 4A growable list of valuations; the <Valuation> part says what it holds. It is not thread-safe, and the parallel body below writes to it.

  BackNext line

  Say it

  A List is not thread-safe, so Parallel.ForEach lost adds. We write each result into its own array slot by index, then save once after the loop. That removes the race and the lock.

• The async lambda returned before the saves finished

  The worker log:
  "Valuation job finished in 03:10"
  Then, twenty minutes later:
  Unhandled exception. System.ObjectDisposedException: Cannot access a disposed object.
  Process exited with code 134.

  Cause

  Parallel.ForEach takes an Action<T>, a method that returns nothing. An async lambda passed there becomes async void: the loop calls it, it runs to its first await, and returns to the loop at once. Parallel.ForEach thinks the iteration is finished. The loop returns, the job logs success, the host disposes the writer created for this job, and the saves still in flight fail. An exception from async void is raised on the pool, not on the caller, so it crashes the process.

  Fix

  Use await Parallel.ForEachAsync(...). It takes an async body, awaits every call, and returns only when all of them finish. MaxDegreeOfParallelism limits how many saves are in flight, and the scoped writer stays alive until the loop returns. A failure comes back at the await.

  BeforeAfter

  Diagram · step 1Parallel.ForEach gets an async lambda. It expects a method that returns nothing.Show diagram

  The jobone run

  Thread poolreused workers

  The writersaves rows

  Azure SQLvaluation table

  async lambda

  1Parallel.ForEach(leases, async lease =>2{3 await writer.SaveAsync(lease);4});5logger.LogInformation("Done");

  Before · ValuationJob.cs · line 1 · 1 of 3The lambda is async, but Parallel.ForEach wants an Action: a method that returns nothing. The compiler makes it async void.

  BackNext line

  Say it

  Parallel.ForEach cannot await an async lambda; it becomes async void, so the loop returns before the saves finish. We moved to Parallel.ForEachAsync with a max degree, so the await covers every save and a failure reaches the caller.

Traps

• Don't sayA Task is a thread.SayA Task is a promise. It may use a pool thread, or no thread at all while an I/O wait is pending.
• Don't sayParallel.ForEach makes every loop faster.SayOnly CPU-bound work with a body big enough to pay the split cost (the time to cut up the list and hand it out). I/O, small collections and shared locks make it slower.
• Don't sayasync makes the method run on a new thread.SayIt frees the current thread at an await; the continuation runs on a pool thread later. No thread is created for the wait.
• Don't sayParallel.ForEach stops at the first exception.SayIt stops starting new iterations, lets the running ones finish, then throws one AggregateException holding every failure that happened.

Traps

What should you say instead? Tap to check.

• Don't sayA Task is a thread.

  Say instead

  A Task is a promise. It may use a pool thread, or no thread at all while an I/O wait is pending.

• Don't sayParallel.ForEach makes every loop faster.

  Say instead

  Only CPU-bound work with a body big enough to pay the split cost (the time to cut up the list and hand it out). I/O, small collections and shared locks make it slower.

• Don't sayasync makes the method run on a new thread.

  Say instead

  It frees the current thread at an await; the continuation runs on a pool thread later. No thread is created for the wait.

• Don't sayParallel.ForEach stops at the first exception.

  Say instead

  It stops starting new iterations, lets the running ones finish, then throws one AggregateException holding every failure that happened.