ConfigureAwait (false) เกี่ยวข้องใน ASP.NET Core หรือไม่

108

ฉันพบปัญหา ( https://github.com/HTBox/allReady/issues/1313 ) ที่ GitHub ซึ่งพวกเขาคุยกันเกี่ยวกับการConfigureAwait(false)เอาโค้ดออกโดยอ้างว่าในASP.NET Core

การโทรไปConfigureAwait(false)ซ้ำซ้อนและไม่ทำอะไรเลย

สิ่งที่ดีที่สุดที่ฉันสามารถหาได้ที่นี่คือ "บันทึกด้านข้าง" ในคำตอบ (จาก Stephen Cleary, https://stackoverflow.com/a/40220190/2805831 ) บอกว่า

ASP.NET Core ไม่มี "บริบท" อีกต่อไป

ดังนั้นจึงConfigureAwait(false)ไม่จำเป็นจริงๆในASP.NET Core (แม้ว่าจะใช้. Net Framework แบบเต็ม)? มันมีประสิทธิภาพที่แท้จริงในบางกรณีหรือไม่หรือความแตกต่างในผลลัพธ์ / ความหมาย?

แก้ไข:ในแง่มุมนี้จะแตกต่างกันหรือไม่ถ้าฉันโฮสต์เป็นแอปพลิเคชันคอนโซลหรือใน IIS

.net asp.net-core async-await

— เปโดรลอเรนซ์
แหล่งที่มา

ขึ้นอยู่กับตำแหน่งที่คุณวางแผนจะใช้ หากคุณต้องการใช้โดยตรงในแอปพลิเคชัน ASP.NET Core ของคุณคุณก็ไม่จำเป็นต้องเรียกมัน (คุณไม่จำเป็นต้องเรียกมันใน ASP.NET ดั้งเดิมหรือ iirc) แต่ถ้าคุณเขียนไลบรารีคุณควรใช้เสมอConfigureAwait(false)เนื่องจากแอปพลิเคชั่นต่างๆสามารถใช้งาน ไลบรารีได้ (ASP.NET Core, WPF, UWP, Console เป็นต้น)

— Tseng

ASP.NET Core ทำงานเป็นแอปพลิเคชันคอนโซลตามค่าเริ่มต้นและแอปพลิเคชันคอนโซล AFAIK ไม่มี SynchronizationContext ดังนั้นใช่สิ่งนี้ฟังดูสมเหตุสมผลสำหรับแอปพลิเคชัน ASP.NET Core เริ่มต้นแม้จะมี Framework แบบเต็มก็ตาม

— Joe White

@JoeWhite ตกลงแก้ไขคำถาม จะแตกต่างกันไหมถ้าแอพ ASP.NET Core ของฉันอยู่ใน IIS

— Pedro Lorentz

แอป ASP.NET Core ที่ทำงานใน IIS ยังคงทำงานเป็นแอปพลิเคชันคอนโซลข้อแตกต่างเพียงอย่างเดียวคือ IIS เริ่มต้นและปิดอินสแตนซ์ของแอปของคุณ (เช่นเดียวกับที่มีการจัดการอินสแตนซ์ของกระบวนการผู้ปฏิบัติงาน ASP.NET ใน ASP.NET แบบคลาสสิก) มันจะไม่เปลี่ยนพฤติกรรมที่เกี่ยวข้องกับเธรดใด ๆ ในแอป ASP.NET ของคุณ (เหตุผลเดียวที่ฉันระบุ "โดยค่าเริ่มต้น" คือคุณสามารถโฮสต์ ASP.NET Core ภายในแอป GUI ได้เช่นกันและในกรณีนี้คุณจะต้องคิดถึงบริบทการซิงโครไนซ์)

— Joe White

หมายเหตุ: ConfigureAwait(false)ในขณะที่เกี่ยวข้องใน ASP.NET คลาสสิกโดยหมายความว่าไม่มีความจำเป็น มันเป็นการแลกเปลี่ยน: มันช่วยลดการหยุดชะงักของการซิงค์เกิน async (ซึ่งเป็นข้อบกพร่องในการออกแบบอยู่ดี - ไม่มีอยู่จริงเว้นแต่จะมีคนทำอะไรโง่ ๆ ) และบางครั้งก็มีการเพิ่มประสิทธิภาพ ~ ไมโครวินาทีโดยไม่โหลดบริบทใหม่ ในราคาที่ไม่สามารถขึ้นอยู่กับบริบทและมีConfigureAwaitทั้งหมดผ่านโค้ดของคุณ stackoverflow.com/questions/28221508/…

— Dax Fohl

คำตอบ:

115

ConfigureAwaitมีผลเฉพาะกับโค้ดที่ทำงานในบริบทSynchronizationContextที่ ASP.NET Core ไม่มี (ASP.NET "Legacy")

รหัสวัตถุประสงค์ทั่วไปยังควรใช้เนื่องจากอาจทำงานด้วยไฟล์SynchronizationContext.

ASP.NET Core SynchronizationContext

— Paulo Morgado
แหล่งที่มา

เพียงต้องการชี้แจงเล็กน้อย ASP.NET ในสภาพแวดล้อมที่ไม่ใช่คอร์จะมีบริบทการซิงค์ แต่แกน ASP.NET ไม่มี

— Scott Chamberlain

@ มอร์กาโดจริงหรือไม่แม้ว่าแอปจะโฮสต์ใน IIS ก็ตาม

— Pedro Lorentz

แอป ASP.NET Core ไม่ได้โฮสต์ใน IIS IIS ทำหน้าที่เป็น reverse proxy

— Paulo Morgado

ฉันได้อัปเดตคำตอบด้วยโพสต์ล่าสุดจาก Stephen Cleary แต่ใช่ ASP.NET Core คือ ASP.NET Core

— Paulo Morgado

@NamNgo. ชื่นชมนี่เป็นโพสต์เก่าในตอนนี้ แต่ Stephen Cleary ชี้แจงเรื่องนี้ในคำถามหนึ่งในโพสต์ที่ Paulo เชื่อมโยงไว้ "เป็นเฟรมเวิร์ก (ASP.NET Core ซึ่งตรงข้ามกับ ASP.NET Classic) ที่กำหนด SynchronizationContext ไม่ใช่รันไทม์ (.NET Core เมื่อเทียบกับ. NET 4.6.2)"

— Gavin Sutherland

อะไรประมาณนี้

ในขณะนี้ (ก.พ. 2563) นักพัฒนาใน MS Blog แนะนำให้ใช้ ConfigureAwait (false) เพื่อปรับปรุงประสิทธิภาพหลีกเลี่ยงการหยุดชะงัก https://devblogs.microsoft.com/dotnet/configureawait-faq/

ฉันเคยได้ยินว่า ConfigureAwait (false) ไม่จำเป็นใน. NET Core อีกต่อไป จริงหรือ? เท็จ จำเป็นเมื่อรันบน. NET Core ด้วยเหตุผลเดียวกันกับที่จำเป็นเมื่อรันบน. NET Framework ไม่มีอะไรเปลี่ยนแปลงในเรื่องนั้น

— Alfred Severo
แหล่งที่มา

หากรหัสผู้ใช้บางส่วน (หรือรหัสไลบรารีอื่น ๆ ที่แอปของคุณใช้) ตั้งค่าบริบทที่กำหนดเองและเรียกใช้รหัสของคุณหรือเรียกใช้รหัสของคุณในงานที่กำหนดเวลาให้กับ TaskScheduler ที่กำหนดเองแม้แต่ใน ASP.NET Core การรอคอยของคุณอาจเห็นสิ่งที่ไม่ใช่ บริบทเริ่มต้นหรือตัวกำหนดตารางเวลาที่จะทำให้คุณต้องการใช้ ConfigureAwait (false) แน่นอนในสถานการณ์เช่นนี้หากคุณหลีกเลี่ยงการบล็อกแบบซิงโครนัส (ซึ่งคุณควรหลีกเลี่ยงการทำในเว็บแอปโดยไม่คำนึงถึง) และหากคุณไม่คำนึงถึงค่าใช้จ่ายด้านประสิทธิภาพเพียงเล็กน้อยในเหตุการณ์ที่ จำกัด เช่นนี้คุณอาจหลีกเลี่ยงได้โดยไม่ต้องใช้ ConfigureAwait (เท็จ) .

— Alisson

ตามนั้นฉันว่าสำหรับกรณีส่วนใหญ่มันไม่จำเป็น เว้นแต่คุณจะใช้บริบทการซิงโครไนซ์ที่กำหนดเองหรือใช้ไลบรารีที่ทำเช่นนั้น

— Alisson