ExecuteScalar VS ExecuteScalarAsync+await

[כותבבפורום]

ExecuteScalar VS ExecuteScalarAsync+await

היי,

אחרי שקראתי המון חומר, והבנתי את המשמעות של ExecuteScalarAsync ופונקציונות Async נוספות והבנתי את השימוש ב Wait, הגעתי למסקנה שכדאי לי תמיד להשתמש ב ExecuteScalarAsync מאחר והפונקציה מבצעת את הפעולה תוך פינוי מהיר של ה Thread מה ThreadPool והואיל וכל מה שהפונקציה ExecuteScalarAsync עושה היא המתתנה לתשובה מה- SQL ומשתמשת במשאבי CPU מינוריים בצד שרת ה IIS. האם אני צודק?

לא הצלחתי למצוא סיבה להשתמש ב ExecuteScalar הרגילה לאור האמור מעלה.

בנוסף, מעניין אותי לדעת היכן בעצם "חי" הפרוסס של פונקציות ה Async לאחר שהם מחזירות את ה Thread ל Pool כאשר הן ממתינות.

 

[טרול המתכנן]

אין פה שום עניין של ״כדאי״ או ״טוב״ או ״צודק״.

יש לך API סינכרוני וא-סינכרוני, לפעמים הראשון מתאים ולפעמים השני.
כל הדיבור שלך על ״שימוש במשאבים״ לחלוטין לא רלוונטי. קריאה אסינכרונית, בהגדרה, תמיד תבזבז יותר ״משאבים״ מקוד סינכרוני.

 

[hookedat]

נכון ואתן דוגמא

נאמר שאתה כתבת קוד של GUI ואתה פונה לAPI בקריאה ישירה ולא דרך ת'רד חדש (כלומר קראת לו מהGUI THREAD)

אם אתה עובד סינכרוני, אתה תתקע את הגוי עד הקבלת תשובה, הוא לא יהיה רספונסיבי
אם אתה עובד א-סינכרוני, אתה לא תתקע את הגוי והקוד ימשיך מהמקום שחיכית בו ברגע שתתקבל תשובה ותוכל להמשיך משם..

 

[marvin2]

זה וויכוח סמנטי, אבל קריאות א-סינכרוניות מפנות לך משאבים

טרד שחוזר לטרד פול, ולא יושב תקוע לתשובה זה עוד משאב שחזר לך, ואם תשאיר אותו תקוע על איזו תשובה זה משאב מבוזבז.
&nbsp
וב ASP ממה שהבנתי זה די מורגש.