{"@context":"https://schema.org","@type":"FAQPage","mainEntity":[{"@type":"Question","name":"What is the main role of the 'await' keyword in an asynchronous method?","acceptedAnswer":{"@type":"Answer","text":"The await keyword suspends the execution of the asynchronous method until the Task completes, while freeing the calling thread to process other tasks. This avoids thread blocking and improves application scalability. Unlike Task.Wait() or Task.Result which block the thread, await enables efficient use of thread pool resources."}},{"@type":"Question","name":"Why should async void be avoided except for event handlers?","acceptedAnswer":{"@type":"Answer","text":"Async void methods cannot be awaited and exceptions thrown inside cannot be caught by calling code, causing application crashes. Additionally, unit testing async void methods is impossible as there is no Task to await. Event handlers are the exception because they are called by the framework and cannot return Task."}},{"@type":"Question","name":"In which use case should ValueTask be preferred over Task?","acceptedAnswer":{"@type":"Answer","text":"ValueTask is a value type that avoids heap allocation when the result is already available synchronously, such as in a cache. This reduces garbage collector pressure in high-performance scenarios. Task is always heap-allocated even if the result is synchronous. Use ValueTask only when performance gains are measurable, as incorrect usage can degrade performance."}},{"@type":"Question","name":"What important restriction applies to ValueTask compared to Task?","acceptedAnswer":{"@type":"Answer","text":"ValueTask should only be awaited once as it may be based on a pooled object that will be recycled after use. Multiple awaits can cause subtle bugs. Task can be awaited unlimited times as it is an immutable heap object. If multiple awaits are needed, convert ValueTask to Task using AsTask(). This restriction makes ValueTask unsuitable for scenarios like task caching."}},{"@type":"Question","name":"What is the main purpose of ConfigureAwait(false) in a .NET library?","acceptedAnswer":{"@type":"Answer","text":"ConfigureAwait(false) avoids capturing and restoring the original SynchronizationContext after an await, which improves performance and prevents deadlocks in libraries. In ASP.NET Core, there is no SynchronizationContext so the impact is minimal, but in WinForms/WPF or ASP.NET Framework, it avoids returning to the UI thread or HTTP context. Libraries should always use ConfigureAwait(false) to avoid unnecessary costs."}},{"@type":"Question","name":"Why is ConfigureAwait(false) less critical in ASP.NET Core compared to ASP.NET Framework?","acceptedAnswer":{"@type":"Answer","text":"ASP.NET Core does not use a SynchronizationContext by default, so the continuation already executes on an arbitrary thread pool thread. ConfigureAwait(false) therefore has negligible performance impact. In ASP.NET Framework, there is a SynchronizationContext that captures the HTTP context, which can cause deadlocks if an async method blocks with Wait() or Result. Nevertheless, libraries should always use ConfigureAwait(false) to remain compatible with all contexts."}},{"@type":"Question","name":"What is the best practice for propagating a CancellationToken in an asynchronous method?","acceptedAnswer":{"@type":"Answer","text":"The CancellationToken should be passed as the last method parameter and propagated to all internal asynchronous calls. This enables cascading cooperative cancellation. Never create a new CancellationTokenSource except to create a linked timeout. Regularly check ThrowIfCancellationRequested() in long loops. ASP.NET Core APIs automatically pass HttpContext.RequestAborted as CancellationToken."}},{"@type":"Question","name":"How to correctly implement a timeout with CancellationToken?","acceptedAnswer":{"@type":"Answer","text":"Use CancellationTokenSource.CreateLinkedTokenSource() to combine an existing token with a new CancellationTokenSource(timeout). This allows cancellation either manually via the original token or automatically after timeout. Since .NET 6, use the WaitAsync(TimeSpan) method directly on Task. Never use Task.Delay with CancellationToken as the primary timeout as it does not release resources from the original Task."}},{"@type":"Question","name":"What is the main use case for Task.WhenAll?","acceptedAnswer":{"@type":"Answer","text":"Task.WhenAll allows waiting for the completion of multiple independent tasks in parallel and retrieves all results in an array. It is optimal for independent I/O operations like multiple HTTP calls. If a Task fails, WhenAll still waits for all others before throwing an AggregateException. To get all results even with partial errors, use individual error handling techniques."}},{"@type":"Question","name":"What is the main use case for Task.WhenAny?","acceptedAnswer":{"@type":"Answer","text":"Task.WhenAny returns as soon as the first task completes (success or failure), which is useful for implementing timeouts, retry with the fastest response, or processing results as they arrive. Unlike WhenAll, WhenAny only retrieves a single completed task and others continue running in the background unless explicitly cancelled. Often combined with CancellationToken to cancel remaining tasks."}},{"@type":"Question","name":"How to handle exceptions when multiple tasks fail in Task.WhenAll?","acceptedAnswer":{"@type":"Answer","text":"Task.WhenAll throws an AggregateException containing all exceptions from failed tasks. However, with await, only the first exception is rethrown. To access all exceptions, do not use await but access task.Exception.InnerExceptions. Alternatively, wrap each task in a try-catch to handle errors individually. Since C# 10, use pattern matching to handle different exception types."}},{"@type":"Question","name":"What happens if an exception in an asynchronous Task is never observed (await, Wait, Result)?","acceptedAnswer":{"@type":"Answer","text":"In .NET 4.5+, unobserved exceptions are simply ignored and no longer crash the application by default. They are available via TaskScheduler.UnobservedTaskException for logging. This is a change from .NET 4.0 where it caused crashes. However, this is bad practice as errors are silent. Always observe tasks with await or access task.Exception. Use Task.Run only with await or ContinueWith."}},{"@type":"Question","name":"What classic pattern causes a deadlock with async/await in WinForms or WPF?","acceptedAnswer":{"@type":"Answer","text":"Calling .Result or .Wait() on an asynchronous Task from the UI thread blocks the thread waiting for completion. However, the continuation after await attempts to return to the UI thread (via SynchronizationContext), which is blocked, creating a deadlock. Solution: always use await instead of .Result/.Wait(), or use ConfigureAwait(false) in library code. ASP.NET Core does not have this problem as it has no SynchronizationContext."}},{"@type":"Question","name":"How to detect a potential deadlock in async/await code during a code review?","acceptedAnswer":{"@type":"Answer","text":"Look for blocking calls .Result, .Wait(), .GetAwaiter().GetResult() on asynchronous Tasks, especially in contexts with SynchronizationContext (UI, ASP.NET Framework). Check for missing ConfigureAwait(false) in library code. Analyze locks (lock, SemaphoreSlim) used around async code. Use Roslyn analyzers like AsyncFixer to automatically detect these patterns. Profiling tools like dotTrace can identify blocked threads."}},{"@type":"Question","name":"Why use SemaphoreSlim instead of lock (Monitor) in async code?","acceptedAnswer":{"@type":"Answer","text":"The lock keyword cannot be used with await as it relies on Monitor which is incompatible with asynchronous methods (compilation error). SemaphoreSlim provides WaitAsync() which allows asynchronous waiting without blocking the thread. Use SemaphoreSlim(1,1) to simulate an exclusive lock. Always use try-finally to guarantee Release() even on exceptions. For simple scenarios, prefer lock with synchronous code."}},{"@type":"Question","name":"What is the main advantage of IAsyncEnumerable introduced in C# 8?","acceptedAnswer":{"@type":"Answer","text":"IAsyncEnumerable allows streaming asynchronous data as it arrives without loading the entire collection into memory. Use await foreach to consume elements. Ideal for large database queries (EF Core), reading large files, or API data streaming. Combined with yield return, it enables lazy element production. Supports CancellationToken via ConfigureAwait. More memory-efficient than loading the entire list with ToListAsync()."}},{"@type":"Question","name":"How to pass a CancellationToken to a method returning IAsyncEnumerable?","acceptedAnswer":{"@type":"Answer","text":"Use the [EnumeratorCancellation] attribute on the CancellationToken parameter of the method. When calling with await foreach, pass the token via .WithCancellation(token). This enables cancellation during asynchronous iteration. Without this attribute, the compiler does not correctly bind the token to GetAsyncEnumerator. Always check cancellationToken.ThrowIfCancellationRequested() in loops. Since C# 9, this is part of the standard async streams pattern."}},{"@type":"Question","name":"What is the advantage of Parallel.ForEachAsync introduced in .NET 6 compared to Task.WhenAll?","acceptedAnswer":{"@type":"Answer","text":"Parallel.ForEachAsync allows controlling the maximum degree of parallelism with ParallelOptions.MaxDegreeOfParallelism, avoiding resource or external API saturation. Task.WhenAll launches all tasks immediately without limit. Natively supports CancellationToken. Useful for processing large collections with a limited number of simultaneous requests. Combines the advantages of Parallel.ForEach (parallelism control) and async/await (non-blocking)."}},{"@type":"Question","name":"In which cases does ValueTask use object pooling to optimize performance?","acceptedAnswer":{"@type":"Answer","text":"ValueTask can use IValueTaskSource to pool reusable objects in very high-performance scenarios like network I/O operations with SocketAsyncEventArgs. Most of the time, ValueTask is a struct wrapping either a synchronous result (T) or a Task. Pooling via IValueTaskSource is an advanced pattern rarely needed except in low-level system libraries. For normal application code, use ValueTask only for common synchronous paths (cache hit)."}},{"@type":"Question","name":"In which use case is it appropriate to use Task.Run in an ASP.NET Core application?","acceptedAnswer":{"@type":"Answer","text":"Task.Run is appropriate only to offload intensive CPU-bound work (calculations, image processing) to the thread pool. Never use Task.Run to wrap asynchronous I/O calls (HttpClient, EF Core) as it wastes a thread. ASP.NET Core already has a thread pool to handle HTTP requests. For heavy CPU-bound work, consider background workers (BackgroundService) rather than blocking an HTTP request. Task.Run is more common in UI applications (WinForms/WPF)."}},{"@type":"Question","name":"Which thread safety mode to use for Lazy in an async ASP.NET Core application?","acceptedAnswer":{"@type":"Answer","text":"Use LazyThreadSafetyMode.ExecutionAndPublication which guarantees a single initialization occurs even with concurrent access. This is the default mode. PublicationOnly allows multiple simultaneous initializations but publishes only the first. None offers no protection and can cause multiple initializations. Warning: Lazy is not async-friendly and can block threads if the initialization delegate is long. For async scenarios, consider SemaphoreSlim with manual lazy initialization."}},{"@type":"Question","name":"What is the main role of AsyncLocal in asynchronous code?","acceptedAnswer":{"@type":"Answer","text":"AsyncLocal allows storing data that is automatically propagated through async/await calls, even when continuations switch threads. Unlike ThreadLocal which is tied to the physical thread, AsyncLocal follows the asynchronous execution context. Useful for log correlation (trace ID), user context, or culture information. Changes in a child context do not propagate to the parent. Performance cost to consider for high-frequency scenarios."}},{"@type":"Question","name":"Why is it generally recommended to use async/await instead of ContinueWith?","acceptedAnswer":{"@type":"Answer","text":"async/await provides simpler and more readable syntax, automatically handles exceptions via standard try-catch, and correctly propagates SynchronizationContext. ContinueWith requires manually handling TaskContinuationOptions, error handling via task.Exception, and can create subtle bugs with TaskScheduler. ContinueWith remains useful for advanced scenarios like conditional branching based on TaskStatus or guaranteed execution with TaskContinuationOptions.OnlyOnFaulted."}},{"@type":"Question","name":"Which async pattern can cause a memory leak in a long-running application?","acceptedAnswer":{"@type":"Answer","text":"Creating Tasks without awaiting them or storing them in a collection without ever cleaning them creates a memory leak. Closures capturing large objects in non-terminating async lambdas keep those objects in memory. Undisposed CancellationTokenSource can accumulate callbacks. Async event handlers that do not unsubscribe maintain references. Always await tasks, dispose CancellationTokenSource, and unsubscribe from events in Dispose/DisposeAsync."}},{"@type":"Question","name":"How to correctly implement a fire-and-forget pattern in ASP.NET Core?","acceptedAnswer":{"@type":"Answer","text":"Use IHostedService or BackgroundService for background tasks rather than unawaited Task.Run. If truly necessary in an HTTP request, use IBackgroundTaskQueue to queue work and process it via a BackgroundService. Never launch unawaited Tasks in a controller as they can be killed during app shutdown. Always log exceptions from fire-and-forget tasks. Avoid this pattern unless absolutely necessary as it complicates debugging and testing."}},{"@type":"Question","name":"What naming convention is recommended for asynchronous methods in .NET?","acceptedAnswer":{"@type":"Answer","text":"Asynchronous methods should have the 'Async' suffix (e.g., GetDataAsync, SaveAsync) according to Microsoft guidelines. This allows immediately identifying that a method is asynchronous during code review. Exception: async event handlers (not OnClickAsync but simply OnClick). For interfaces, define both sync and async overloads if necessary (Read/ReadAsync). This convention improves readability and avoids confusion between sync and async versions of the same method."}}]}