TPL

Question 1

What does ConfigureAwait(false) do?

Answer 1

Continues the async operation without capturing the current synchronization context, allowing the continuation to run on any thread. Improves performance in libraries where returning to the original context isn’t required.

Question 2

Why should you usually use ConfigureAwait(false) in libraries?

Answer 2

To avoid deadlocks in UI or ASP.NET contexts and improve performance by not forcing the continuation back to the original context.

Question 3

Difference between Task.Run(async () => …) and await SomeAsyncMethod()?

Answer 3

• Task.Run: Queues work to ThreadPool; may create a new thread.
• await SomeAsyncMethod(): Asynchronously waits for the operation without blocking the calling thread; continuation may run on the original context unless ConfigureAwait(false) is used.

Question 4

What happens if you forget await in an async method?

Answer 4

The async method starts but the calling method doesn’t wait for it, potentially causing unobserved exceptions or race conditions

Question 5

Difference between blocking and non-blocking calls in HTTPClient: Post() vs PostAsync()?

Answer 5

Post(): Synchronously blocks the calling thread until the request completes.

PostAsync(): Asynchronously sends the request; doesn’t block the calling thread.

Question 6

When should you use Task.Run in an ASP.NET application?

Answer 6

Only for CPU-bound work that would otherwise block the request thread. For I/O-bound async operations, just use await without Task.Run.

Question 7

What is the risk of using Task.Run(() => GetDataAsync()) without await?

Answer 7

You may create a nested Task, lose exceptions, and potentially run into unobserved exceptions or unfinished work.

Question 8

What is the risk of not using ConfigureAwait(false) in library code?

Answer 8

In a UI or ASP.NET context, awaiting may try to resume on the original synchronization context, potentially causing deadlocks or performance issues.

Question 9

What happens when multiple exceptions occur in parallel tasks?

Answer 9

They are wrapped into an AggregateException.

You were right — Task.WaitAll, Task.WhenAll, or similar APIs wrap multiple exceptions in an AggregateException.

Question 10

What is the difference between Wait() and await when handling exceptions?

Answer 10

Wait() (or Result) will throw an AggregateException, even if there’s just a single exception.

await will unwrap the exception and throw the original exception (not wrapped).

Question 11

Q3: What happens if the first completed task in Task.WhenAny throws an exception?

Answer 11

The exception is stored in the returned task.

Task.WhenAny itself doesn’t throw — it just returns the first completed task (success, faulted, or canceled).

You must await the returned task to observe the exception.

var t1 = Task.Run(() => throw new InvalidOperationException());
var t2 = Task.Delay(1000);

var first = await Task.WhenAny(t1, t2);

try
{
await first; // Exception thrown here
}
catch (InvalidOperationException ex)
{
Console.WriteLine($”Caught: {ex.Message}”);
}

Question 12

IsFaulted and Task.Exception property

Answer 12

var t = Task.Run(() => throw new Exception(“Error”));

t.Wait(); // or just let it finish

if (t.IsFaulted)
Console.WriteLine($”Task failed: {t.Exception.InnerException.Message}”);

Question 13

What is Task.GetAwaiter()

Answer 13

Every Task (or Task<T>) has a GetAwaiter() method.</T>

Normally, you don’t call it yourself — it’s used by the C# compiler when you write await task;.

Example:
Task<int> task = Task.Run(() => 42);
var awaiter = task.GetAwaiter(); // returns a TaskAwaiter<int></int></int>

int value = await task;
into something like:

var awaiter = task.GetAwaiter();
if (!awaiter.IsCompleted)
{
awaiter.OnCompleted(() => { /* resume method */ });
}
int value = awaiter.GetResult();
👉 You don’t normally call GetAwaiter() directly — unless you’re writing low-level libraries (e.g., custom awaitable types).

Question 14

Whast is Task.GetResult()

Answer 14

Used internally by await.

Returns the result if task completed successfully, otherwise:

Throws the original exception (not AggregateException).

⚠️ If task is not completed, GetResult() will block until completion.
Task<int> task = Task.Run(() => 1 / 0);
var awaiter = task.GetAwaiter();
try
{
int result = awaiter.GetResult();
}
catch (Exception ex)
{
Console.WriteLine(ex.GetType()); // DivideByZeroException (original)
}</int>

Question 15

Task.Wait()

Answer 15

Blocks the current thread until the task is finished.

If the task faulted, it throws AggregateException.

Should be avoided in async code (can cause deadlocks in UI or ASP.NET contexts).

Use await instead of Wait() whenever possible.

Question 16

✅ Prefer

await (best choice for async code)

Lets compiler handle GetAwaiter/GetResult

Exceptions are automatically unwrapped

Answer 16

🚫 Avoid (unless you have good reason)

Wait() and .Result → cause blocking & AggregateException

GetAwaiter() + GetResult() manually → only for low-level libraries or writing custom awaitable logic

Question 17

: What does Task.Wait() do, and why can it be dangerous?

Answer 17

Wait() blocks the calling thread until the task finishes. If the task throws an exception, it wraps it in an AggregateException. It can cause deadlocks (especially in UI contexts like WinForms/WPF/ASP.NET) and should be avoided in async code.

Question 18

What does accessing Task.Result do, and why should it be used carefully?

Answer 18

Result blocks the calling thread until the task finishes and then returns the result. If an exception occurs, it’s wrapped in an AggregateException. Like Wait(), it can deadlock in async contexts. Use await instead in async code.

Question 19

What does GetAwaiter() return, and when is it useful?

Answer 19

GetAwaiter() returns a TaskAwaiter (or ConfiguredTaskAwaiter), which allows fine-grained control over awaiting a task. Normally you don’t call it directly, since await uses it under the hood, but it’s useful when building custom awaiters or writing lower-level async infrastructure.

Question 20

: What does GetResult() do when called on a task’s awaiter?

Answer 20

GetResult() blocks until the task is finished and returns the result. If the task failed, it throws the original exception (not wrapped in AggregateException). This is different from Wait() and Result.

Question 21

Why is await task usually preferred over task.Wait() or task.Result?

Answer 21

Because await is non-blocking, avoids deadlocks, unwraps exceptions automatically, and allows the continuation to resume on the right synchronization context. It’s the recommended way in modern async code.

Question 22

✅ So what’s the difference?

Wait() & Result: block + wrap exception in AggregateException.

GetAwaiter().GetResult(): block + throw original exception.

That’s the real distinction.

None of them are truly “non-blocking” when the task isn’t finished. They all block the calling thread if the task is still running. The only non-blocking way is using await task.

Answer 22

⚠️ Why avoid them?

They block threads → kills the benefit of async.

In UI apps (WinForms, WPF, ASP.NET old synchronization context), they can cause deadlocks.

Best practice: always use await.

Question 23

What is Task.ContinueWith used for?

Answer 23

It creates a continuation task that runs after the antecedent task completes, regardless of its final state (success, fault, canceled).

Question 24

What does ContinueWith return?

Answer 24

It returns a new Task (or Task<TResult>) representing the continuation, not the original task.</TResult>

Question 25

How do you ensure a continuation runs only when the antecedent completes successfully?

Answer 25

Use ContinueWith with TaskContinuationOptions.OnlyOnRanToCompletion.

Question 26

How do you ensure a continuation runs only when the antecedent fails?

Answer 26

Use ContinueWith with TaskContinuationOptions.OnlyOnFaulted.

Question 27

How do you ensure a continuation runs only when the antecedent is canceled?

Answer 27

Use ContinueWith with TaskContinuationOptions.OnlyOnCanceled.

Question 28

What’s the difference between ContinueWith and await?

Answer 28

await automatically marshals exceptions, cancellation, and resumes on the captured context, while ContinueWith is lower-level and requires explicit handling of state and exceptions.

Question 29

When should you prefer ContinueWith over await?

Answer 29

Prefer ContinueWith when you need fine-grained control over continuation conditions, custom TaskScheduler, or chaining complex task graphs. Otherwise, use await for readability and simplicity.

Question 30

Can ContinueWith run synchronously?

Answer 30

Yes, by specifying TaskContinuationOptions.ExecuteSynchronously, but only if the antecedent is already completed.

Question 31

Can multiple continuations be attached to the same task?

Answer 31

Yes, you can attach multiple ContinueWith calls to one task, and each continuation will run independently when the task completes.

Question 32

What happens if an exception occurs in a continuation?

Answer 32

The exception is captured in the continuation task. If unobserved, it may cause the process to terminate unless handled.

Question 33

How do you wait for a Task to complete and propagate its exception?

Answer 33

Use task.Wait() or task.Result; both block the current thread and throw exceptions wrapped in AggregateException.

Question 34

How do you retrieve the result of a completed Task without blocking?

Answer 34

Use await task; it will asynchronously wait without blocking the current thread.

Question 35

How do you run a continuation only if the Task completes successfully?

Answer 35

Use ContinueWith with TaskContinuationOptions.OnlyOnRanToCompletion.

Question 36

How do you run a continuation if the Task fails?

Answer 36

Use ContinueWith with TaskContinuationOptions.OnlyOnFaulted.

Question 37

How do you run a continuation if the Task is canceled?

Answer 37

Use ContinueWith with TaskContinuationOptions.OnlyOnCanceled.

Question 38

How do you synchronously retrieve the result of a Task without wrapping in AggregateException?

Answer 38

Use task.GetAwaiter().GetResult(); it throws the original exception instead of AggregateException but blocks if the Task isn’t completed.

Question 39

How do you combine await with ContinueWith to handle both success and failure?

Answer 39

Use await for normal flow, and attach ContinueWith for faulted/canceled cases. Example: `task.ContinueWith(t => HandleError(t), TaskContinuationOptions.NotOnRanToCompletion); var result = await task;`

Question 40

What Thread.Sleep() does?

Answer 40

Thread.Sleep(2000); // blocks current thread for 2 seconds Behavior: Blocks the current thread completely. Thread cannot do anything else during the sleep. In a UI app (WPF/WinForms), it freezes the UI if used on the UI thread. In a web app (ASP.NET Core), blocking a thread reduces scalability because the thread cannot handle other requests. Use cases: Rarely recommended in async scenarios. Sometimes used in console apps or low-level threading scenarios.

Question 41

What Task.Delay() does?

Answer 41

await Task.Delay(2000); // asynchronously waits for 2 seconds Behavior: Non-blocking delay. The thread is released back to the thread pool while waiting. In async methods, other work can continue during the delay. Perfect for UI responsiveness and highly scalable web apps. Use cases: Simulating asynchronous work. Waiting between retries in async code. Throttling operations without blocking threads.

Question 42

Difference between Thread.Sleep() and Task.Delay()

Answer 42

Feature Thread.Sleep Task.Delay Thread blocking ✅ Blocks thread ❌ Does NOT block thread Async-friendly ❌ No ✅ Yes (with await) UI responsivenes ❌ Freezes UI ✅ UI stays responsive Scalability ❌ Bad for servers✅ Good for servers ⚡ Rule of Thumb: Use Thread.Sleep only in synchronous, blocking code. Use Task.Delay in async code to avoid blocking threads.

Question 44

00What is TPL in .NET?

Answer 44

The Task Parallel Library (TPL) provides high-level APIs for creating and managing tasks for parallel and asynchronous programming without manually handling threads.

Question 45

Why limit concurrency in TPL?

Answer 45

To prevent CPU, memory, or I/O resource exhaustion, avoid thread pool starvation, and optimize throughput.

Question 46

What is SemaphoreSlim used for in TPL?

Answer 46

To control the number of concurrently running tasks, especially for async operations.

Question 47

How do you use SemaphoreSlim with async tasks?

Answer 47

await semaphore.WaitAsync(); try { await DoWorkAsync(); } finally { semaphore.Release(); }

Question 48

What is MaxDegreeOfParallelism?

Answer 48

A property in ParallelOptions that sets the maximum number of concurrent tasks in Parallel.For, Parallel.ForEach, or Parallel.Invoke.

Question 49

How do you limit concurrency in Parallel.ForEach?

Answer 49

var options = new ParallelOptions { MaxDegreeOfParallelism = 4 }; Parallel.ForEach(items, options, item => ProcessItem(item));

Question 50

Difference between SemaphoreSlim and MaxDegreeOfParallelism?

Answer 50

SemaphoreSlim works for async tasks and gives fine-grained control; MaxDegreeOfParallelism is simpler and mainly for CPU-bound synchronous operations.

Question 51

Can Task.WhenAll control concurrency?

Answer 51

No, Task.WhenAll waits for all tasks to complete but does not limit how many run concurrently.

Question 52

How can TPL Dataflow help limit concurrency?

Answer 52

ActionBlock or TransformBlock allow MaxDegreeOfParallelism to limit parallel processing of messages.

Question 53

Example of limiting concurrency with ActionBlock:

Answer 53

var options = new ExecutionDataflowBlockOptions { MaxDegreeOfParallelism = 5 }; var block = new ActionBlock(async item => await DoWorkAsync(item), options); items.ForEach(block.Post); block.Complete(); await block.Completion;

Question 54

Why is it dangerous to start too many tasks at once?

Answer 54

It can exhaust the thread pool, increase memory usage, cause high CPU load, and reduce overall performance.

Question 55

How does Parallel.ForEachAsync help with async concurrency?

Answer 55

In .NET 6+, it allows processing async delegates with a MaxDegreeOfParallelism option.

Question 56

Example of Parallel.ForEachAsync limiting concurrency:

Answer 56

await Parallel.ForEachAsync(items, new ParallelOptions { MaxDegreeOfParallelism = 3 }, async (item, token) => { await DoWorkAsync(item); });

Question 57

What is the default degree of parallelism in Parallel.ForEach?

Answer 57

By default, it uses Environment.ProcessorCount to decide the number of concurrent tasks.

Question 58

How can you throttle tasks without SemaphoreSlim?

Answer 58

Using TPL Dataflow, ParallelOptions.MaxDegreeOfParallelism, or a custom task queue with limited workers.

Question 59

Can you mix async and Parallel.ForEach?

Answer 59

You should avoid Parallel.ForEach for async delegates; instead, use Parallel.ForEachAsync or SemaphoreSlim.

Question 60

How do you handle exceptions when limiting concurrency?

Answer 60

Use try/finally to release semaphores and Task.WhenAll to aggregate exceptions.

Question 61

Why is SemaphoreSlim.WaitAsync() preferred over Wait() for async tasks?

Answer 61

WaitAsync() is non-blocking and prevents thread starvation, while Wait() blocks a thread unnecessarily.

Question 62

Can limiting concurrency improve performance for I/O-bound tasks?

Answer 62

Yes, because it prevents overwhelming I/O resources and allows optimal throughput.

Question 63

Can limiting concurrency hurt performance for CPU-bound tasks?

Answer 63

If the limit is too low, it can underutilize CPU cores; the optimal limit is usually equal to the number of logical cores.

Question 64

How can you create a reusable throttling helper for async tasks?

Answer 64

async Task RunThrottledAsync(IEnumerable items, int maxConcurrency, Func action) { var semaphore = new SemaphoreSlim(maxConcurrency); var tasks = items.Select(async item => { await semaphore.WaitAsync(); try { await action(item); } finally { semaphore.Release(); } }); await Task.WhenAll(tasks); }

Question 65

What is the difference between throttling and batching?

Answer 65

Throttling limits concurrency at runtime; batching processes items in fixed-size groups.

Question 66

How do BlockingCollection and producer-consumer patterns relate to concurrency?

Answer 66

They provide a thread-safe queue with controlled consumer concurrency, limiting simultaneous processing.

Question 67

How can you test if your concurrency limit is effective?

Answer 67

By logging task start/end times and ensuring no more than the desired number of tasks run simultaneously.

Question 68

Key best practices for limiting concurrency in TPL:

Answer 68

Use SemaphoreSlim for async tasks. Use MaxDegreeOfParallelism for synchronous CPU-bound tasks. Handle exceptions and release semaphores in finally. Match concurrency limits to resource capacity (CPU cores, I/O bandwidth). Avoid creating too many tasks at once; batch or queue them if necessary.