ConfigureAwait (false) có liên quan trong ASP.NET Core không?


100

Tôi đã vấp phải một vấn đề ( https://github.com/HTBox/allReady/issues/1313 ) tại GitHub, nơi họ thảo luận về việc lấy ConfigureAwait(false)ra khỏi mã, tuyên bố rằng, trong ASP.NET Core

cuộc gọi đến ConfigureAwait(false)là thừa và không làm gì cả

Điều tốt nhất tôi có thể tìm thấy ở đây là “ghi chú bên lề” trong câu trả lời (từ Stephen Cleary, https://stackoverflow.com/a/40220190/2805831 ) cho biết điều đó

ASP.NET Core không còn "ngữ cảnh"

Vì vậy, có ConfigureAwait(false)thực sự không cần thiết trong ASP.NET Core (ngay cả khi sử dụng .Net Framework đầy đủ)? Nó có bất kỳ lợi ích thực sự nào về hiệu suất trong một số trường hợp hoặc sự khác biệt về kết quả / ngữ nghĩa không?

CHỈNH SỬA: Có gì khác về khía cạnh này nếu tôi đang lưu trữ nó dưới dạng ứng dụng bảng điều khiển hoặc trong IIS không?


2
Điều này phụ thuộc vào nơi bạn định sử dụng nó. Nếu bạn muốn sử dụng nó trực tiếp trong ứng dụng ASP.NET Core của mình, thì bạn không cần phải gọi nó (bạn không cần phải gọi nó trong ASP.NET kế thừa cũng không phải iirc). Nhưng nếu bạn viết thư viện, thì bạn nên luôn sử dụng ConfigureAwait(false), vì thư viện có thể được sử dụng bởi các ứng dụng khác nhau (ASP.NET Core, WPF, UWP, Console, v.v.)
Tseng

1
ASP.NET Core chạy như một ứng dụng bảng điều khiển theo mặc định và các ứng dụng bảng điều khiển AFAIK không có SynchronizationContext, vì vậy có, điều này nghe có vẻ hợp lý đối với ứng dụng ASP.NET Core mặc định, ngay cả với Framework đầy đủ.
Joe White

@JoeWhite Ok, đã chỉnh sửa câu hỏi. Có khác gì nếu ứng dụng ASP.NET Core của tôi ở trong IIS không?
Pedro Lorentz

3
Ứng dụng ASP.NET Core chạy trong IIS vẫn chạy như một ứng dụng bảng điều khiển - sự khác biệt duy nhất là IIS đang khởi động và tắt các phiên bản của ứng dụng của bạn (giống như cách nó sẽ quản lý các phiên bản của quy trình ASP.NET worker trong ASP.NET cổ điển). Nó sẽ không thay đổi bất kỳ hành vi nào liên quan đến luồng bên trong ứng dụng ASP.NET của bạn. (Lý do duy nhất tôi chỉ định "theo mặc định" là bạn có thể, ví dụ: lưu trữ ASP.NET Core bên trong ứng dụng GUI và trong trường hợp đó, bạn sẽ phải suy nghĩ về bối cảnh đồng bộ hóa.)
Joe White

Lưu ý ConfigureAwait(false), mặc dù có liên quan trong ASP.NET cổ điển, nhưng không cần thiết . Đó là một sự cân bằng: nó gần như giảm thiểu một số bế tắc đồng bộ hóa qua không đồng bộ (dù sao cũng là lỗi thiết kế - chúng không tồn tại trừ khi ai đó làm điều gì đó ngu ngốc) và đôi khi có hiệu suất tăng ~ micro giây bằng cách không tải lại ngữ cảnh. Với cái giá phải trả là không thể phụ thuộc vào ngữ cảnh và có ConfigureAwaittất cả thông qua mã của bạn. stackoverflow.com/questions/28221508/…
Dax Fohl

Câu trả lời:


105

ConfigureAwaitchỉ có tác dụng đối với mã chạy trong ngữ cảnh SynchronizationContextmà ASP.NET Core không có (ASP.NET "Legacy" thì có).

Mã mục đích chung vẫn nên sử dụng vì nó có thể đang chạy với SynchronizationContext.

ASP.NET Core SynchronizationContext


17
Chỉ muốn làm rõ một chút, ASP.NET trong môi trường không phải lõi không có ngữ cảnh đồng bộ, nhưng lõi ASP.NET thì không.
Scott Chamberlain

@Morgado, có đúng không ngay cả khi ứng dụng được lưu trữ trong IIS?
Pedro Lorentz

7
Ứng dụng ASP.NET Core không được lưu trữ trong IIS. IIS chỉ hoạt động như một proxy ngược.
Paulo Morgado

2
Tôi đã cập nhật câu trả lời với một bài đăng gần đây của Stephen Cleary. Nhưng, vâng, ASP.NET Core là ASP.NET Core.
Paulo Morgado

14
@NamNgo. Đánh giá cao đây là một bài đăng cũ bây giờ nhưng Stephen Cleary làm rõ điều này trong một trong những câu hỏi về bài đăng mà Paulo đã liên kết ở trên. "đó là khuôn khổ (ASP.NET cốt lõi như trái ngược với ASP.NET cổ điển) mà xác định SynchronizationContext, không phải là thời gian chạy (NET cốt lõi như trái ngược với .NET 4.6.2)"
Gavin Sutherland

14

Cái này thì sao?

Tại thời điểm này (tháng 2 năm 2020) Các nhà phát triển trên MS Blog khuyên bạn nên sử dụng ConfigureAwait (false) để Cải thiện hiệu suất, Tránh bế tắc. https://devblogs.microsoft.com/dotnet/configureawait-faq/

Tôi đã nghe nói ConfigureAwait (false) không còn cần thiết trong .NET Core. Thật? Sai. Nó cần khi chạy trên .NET Core vì chính xác những lý do nó cần khi chạy trên .NET Framework. Không có gì thay đổi về mặt đó.


Nếu một số mã người dùng (hoặc mã thư viện khác mà ứng dụng của bạn đang sử dụng) đặt ngữ cảnh tùy chỉnh và gọi mã của bạn hoặc gọi mã của bạn trong một Tác vụ được lên lịch cho TaskScheduler tùy chỉnh, thì ngay cả trong ASP.NET Core, sự chờ đợi của bạn có thể thấy không ngữ cảnh hoặc trình lập lịch mặc định dẫn bạn đến việc muốn sử dụng ConfigureAwait (false). Tất nhiên, trong những tình huống như vậy, nếu bạn tránh chặn đồng bộ (điều mà bạn nên tránh làm trong các ứng dụng web bất kể) và nếu bạn không bận tâm đến chi phí hiệu suất nhỏ trong những lần xuất hiện hạn chế như vậy, bạn có thể thoát khỏi mà không cần sử dụng ConfigureAwait (false) .
Alisson

1
Theo đó, tôi sẽ nói đối với hầu hết các trường hợp, nó không cần thiết. Trừ khi bạn đang sử dụng ngữ cảnh đồng bộ hóa tùy chỉnh hoặc sử dụng thư viện làm như vậy.
Alisson
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.