این مورد توضیحش کمی پیچیدس و نیاز داره یه سری موارد رو قبلش بدونین مثل SynchronizationContext و TaskScheduler ( در دوره برنامه نویسی شبکه و چند وظیفه ای کامل این مورد را توضیح دادیم ) ولی خیلی ساده بخوام توضیح بدم اینکه وقتی متد async ایی رو فراخوانی میکنید اون تکه کد داخل متد async ایی توسط یک Thread دیگه [ترد ثانویه] (متفاوت از ترد [اصلی] - ترد فراخوانی کننده متد) اجرا میشه (البته نه الزاما ولی در متد های async IO bound بله)
حالا اگه داخل اون متد async ایی نیاز به دسترسی به اشیایی از Context ترد اصلی نیاز داشته باشید، باید [ترد ثانویه] برگرده به Context ترد اصلی [اصلی] تا بتونه به اشیا اون دسترسی داشته باشه وگرنه خطا میده که "یک ترد نمیتونه به اشیا ترد دیگه دسترسی داشته باشه"

مثلا توی WinForm بخواید مقدار یک کنترل UI مثل TextBox رو بخونید/عوض کنید یا مثلا توی ASPNET MVC (به جز ASP Core چون قضیه اش فرق داره) مثلا بخواهد یه چیزی رو از HttpContext.Current بخونید/تغییر بدید. چون این اشیایی که گفتم مال ترد اصلی هست، ترد ثانویه نمیتونه به اون دسترسی پیدا کنه.

به طور پیشفرض وقتی ما یک متد async رو به صورت عادی await میکنیم، پس از اتمام Task مربوطه، ترد ثانویه برمیگرده به Context ترد اصلی و ما بدون هیچ مشکلی میتونیم به اشیا Context ترد اصلی دسترسی پیدا کنیم ولی این قضیه یه سرباری رو داره تحمیل میکنه که بعضی وقتا بهش نیازی نیست

مثلا وقتی که ما یک کد general-purpose (غیر وابسته به Context خاصی) رو مینویسیم (مثلا کدی که به UI Control ها توی WinForm یا HttpContext.Current توی ASPNET MVC نیازی نداره) مثل یک کد دانلود یک فایل از اینترنت یا انجام عملیات با دیتابیس؛ توی این موارد میتونیم با غیر فعال کردن "بحث Sync شدن Context ها" از این سربار اضافی راحت بشیم

در مقابل وقتی ما داریم یک کد application-level (وابسته به Context خاص) رو مینویسیم (مثلا کدی که به UI Control ها توی WinForm یا HttpContext.Current توی ASPNET MVC نیاز داره) باید این قابلیت رو داشته باشیم حتما وگرنه به مشکل میخوریم (خطای "یک ترد نمیتونه به اشیا ترد دیگه دسترسی داشته باشه")

واسه غیر فعال کردن این امکان باید بر روی متد های async مون از متد ConfigureAwait با مقدار (false) استفاده کنیم . مثال
await httpClient.GetAsync(url).ConfigureAwait(false)
این مورد از dead-lock هم جلوگیری کنه در مواقتی که متد async ایی رو به صورت sync فراخوانی میکنید. مثلا :
asyncMethod.Wait(); یا
asyncMethod.Result; یا
asyncMethod.GetAwaiter().GetResult();

🔰 نتیجه :

🔸وقتی که کد general-purpose مینویسید بهتره از متد ConfigureAwait با مقدار (false) استفاده کنید.

🔹ولی وقتی که کد application-level می‌نویسید به هیچ وجه این کارو نکنید.

🔰نکته :

1️⃣ توی ASPNET Core چون به صورت پیشفرض SynchronizationContext خاص خودش رو نداره فرقی هم نمیکنه از ConfigureAwait استفاده بکنین یا نه (البته تا مادامی که به صورت دستی SynchronizationContext ایی ست نکرده باشین) ...

2️⃣ متد هایی که توسط Task.Run هم اجرا میشن نیازی به ConfigureAwait ندارن چون Task.Run به صورت ضمنی TaskScheduler.Default استفاده میکنه پس SynchronizationContext ترد اجرا کننده null میشه. (اینم تا مادامی که به صورت دستی SynchronizationContext ایی ست نکرده باشین)

🔰در مقاله زیر به سوالات زیر هم پاسخ داده شده :
- What is a SynchronizationContext?
- What is a TaskScheduler?
- What does ConfigureAwait(false) do?
- Why would I want to use ConfigureAwait(false)?
- Why would I want to use ConfigureAwait(true)?
- When should I use ConfigureAwait(false)?
- ...
اطلاعات بیشتر :
https://devblogs.microsoft.com/dotnet/configureawait-faq/