thread-safe ב-C#

[שיווקי]

thread-safe ב-C#

ב-C#

איך מיישמים תוכנה שהיא מרובת משימות באמצעות thread, כאשר משתנים משותפים מוגדרים באופי של thread-safe (איך ניתן להגדירם, שלא ניתן יהיה לשנותם בו זמנית. האם ע"י set ו-get, כ-properties)?
אשמח לדוגמת קוד מעשית.

תודה.

 

[nocgod]

לנעול אותם זו דרך אחת

למה שתרצה לעבוד מול thread ישירות כשיש לך היום TPL?
ואיך הגעת למצא שאתה צריך למגן את הישויות שלך? יש מספיק מבני נתונים מוגנים מפני concurrency.
במקרה הקיצוני לעשות double check lock במקומות שזה חשוב לך.
הייתי ממליץ בחום בתוכנה שהיא כבדה ב IO (יציאה לדיסק, לwebservices או לכל דבר שהוא לא CPU) להשתמש בasync/await ולאו דווקא בthreads כדי לנהל את המשימה הזאת.

 

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

הוא ביקש דוגמת קוד מעשית. תוכל בבקשה לתת אחת?

 

[nocgod]

תיכנס לאתרים שיש בהודעה ויהיו לך דוגמאות קוד

אני לא חושב שיש לי פה איזה צורך לעשות if lock if או איזה צורך עז להתחיל להסביר איך עושים await ל task

 

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

השואל ביקש לראות דוגמת קוד מעשית. תוכל להראות?

 

[nocgod]

לא.

 

[HackPoint]

יש לי שאלה קונקרטית, האם אתה יודע למה צריך async/await?

באמת, מה הסיבה שיצרו את זה? בכדי להגיע למה?
&nbsp
אתה בא ואומר פה דברים, הייתי רוצה להבין לעומק את מה שאתה מנסה להסביר.
אודה אם תוכל לעשות זאת.

 

[nocgod]

עשו אותם בתור סוכר סינטקטי

כדי לכתוב tasks מבלי לעשות ספגטי סגנון JS עם ContinueWith. מעבר לזה אתה רוצה שאתן הסבר מלא למה זה task איך למה וכמה?
מאחר והוא לא הסביר את סגנון התוכנית שלו (webservice, winservice) הצעתי גם פיתרון שאני משתמש בו ביום-יום בפיתוח webapiים בהם אני משתמש בפעולות אסינכרוניות על IO (יציאה לDB או services אחרים) כדי להמנע מתקיעת הthread שיחכה לתשובה אלא יתפנה לטיפול בדברים אחרים. כמו כן גם ציינתי שיש הרבה מבנים שהם thread-safe שבאים עם .net, ולרוב הם אמורים להספיק לו. כדי לבנות קטעים קריטיים הייתי עושה lockים, שוב משהו שהיה יכול להבין מהלינקים שהבאתי לו.

הבחור שאל שאלה רחבה, לא הביא הסבר ללמה הוא צריך את זה, לא הביא הסבר לאיפה הוא צריך את זה.
איך עושים נעילה על משתנים בתוכנית עם threads.
התשובה הכילה את הפיתרון הכי ידוע double checking lock, שיכול לתת לו רעיון לכיווני עבודה, כמובן אפשר לעשות mutexים אם בא לו.

 

[HackPoint]

הראת ידע רחב בת'רדים. לשאלה שלי לא קיבלתי תשובה.

שאלה שלי מאוד פשוטה.
למה צריך את הasync/await?

 

[nocgod]

בגדול לא צריך

 

[HackPoint]

כמו שציינתי הידע שלך בת'רדים הוא רחב

ללא ספק, יש מקום לשיפור אבל זה זניח.
&nbsp
התשובה שציפתי שתענה, ללא כל השטויות שנכתבו ע"י טרול (הוא ציני מדי ואין מה לעשות בנדון).
התשובה היא פשוטה: Scaling. ASYNC/AWAIT נוצרו אף ורק מהסיבה הזו.
ללא שום ת'רד SAFETY הקשור לזה. רק כדי שזה יהיה SCALABLE METHOD INVOCATION
Stephen Cleary
"But the true power of async for server applications comes from scaling requests instead of threads."
&nbsp
"The key in that process is that when the request is waiting (await) asynchronous operations, there are no threads dedicated to that request. Since a request is considerably lightweight compared to a thread, this enables the server to scale better."
&nbsp
אני אשמח להרחיב אם כמובן יהיה צורך לכך, אם לא אדע לתת תשובה לגטימית.
אני ידיד טוב של STEPHEN לכן אם יהיה צורך אוכל לפנות אליו ישירות.

 

[nocgod]

לא רואה שום הבדל בין מה שכתבתי פעמיים למה שכתבת...

נראה כאילו לא קראת את מה שכתבתי, או לא הבנת את מה שקראת (שזה לא נורא)
פעמיים ציינתים שasync await הם סוכר סינטקטים, פעמיים ציינתי שהם מחליפים את task.continuewith (וגם ממומשים ככה מתחת למכסה מנוע)
פעמיים ציינתי שזה לא פותח thread אלא מוותר על thread בזמן io
וכמובן שעל השאלה של ה OP עניתי לפחות 3 פעמים. שאגב כנראה לא טרח לקרוא אותה כי הוא אפילו לא נכנס לדיון אלא רץ לשאול עוד שאלה גנרית למחצה,
שגם אליה את התשובה אפשר לקבל על ידי 4 מילים בגוגל.

 

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

שאלת מדוע נוצרו *המילים השמורות* await/async

התשובה לכך היא *בדיוק* מה שאמר nocgod - הן נוצרו כדי לשפר את הקריאות של קוד אסינכרוני.

לא ייתכן שום קשר בין async/await לבין ״סקלביליות״. כל המנגנונים שמאפשרים קריאות אסינכרוניות היו במקומם איפושהו סביב .net 2.0 - כולל שימוש ב-IOCP.

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

 

[HackPoint]

טרול. מה הקשר?

תראה את התשובה שלי. אני לא מדבר על המילים השמורות אני מדבר על מה זה נותן.

 

[אוהב להתווכח]

ומה התשובה שלך?

אני אשמח לשמוע.
אני מתכווין ברצינות ולא בציניות.

 

[nocgod]

כמו שאמרתי await/async זה סוכר סינטקטי ולא באמת צריך אותו

כל מה שהוא עושה זה מקל על קריאות הקוד עם Task.ContinueWith.
באופן ככלי הרעיון מאחורי פיתוח אסינכרוני הוא להמנע מתקיעת הthread המבצע כשעובדים על IO (לצורך העיניין קריאה מקובץ/socket/webservice/db).
ברגע שיש פעולה אסינכרונית מה שקורה הוא שהthread משתחרר ל pool. כשהפעולה האסינכרונית חוזרת היא נכנסת לqueue ובבוא הזמן, ממשיך הטיפול בפעולה.
זה קצת דומה לצורת הפעולה של nodejs כשבעצם תמיד פעולות IO הן אסינכרוניות וצריך להעביר להן callback (אגב לפי מה ששמעתי בגרסא 7 מעתיקים את הnotion של async/await כדי לפשט קריאות קוד)

Task גם אפשר להריץ על dedicated thread ולעשות לו join או wait או לתת לו continuation.
יותר ממזה ממה שהבנתי ההמלצה היא לא לעשות new Thread אלא דווקא להשתמש בTPL בשביל זה.
עבודה עם async/await היא לא בדיוק עבודה עם threads, אבל אני באמת מאמין שלא כל דבר מצריך שימוש בthreads.
במיוחד בעבודה עם MVC או webapi היום, לא הייתי עושה threads, הייתי עושה (ואני עושה) הכל async.

 

[אוהב להתווכח]

תודה

נשמח לקבל גם כן את תגובתו של האקפוינט

 

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

המשפט הראשון הוא תשובה טובה מאד לשאלה.

זו תשובה מדוייקת בדיוק ברמה הדרושה.
את השאר מוטב שלא היית טורח לכתוב.

כן, אני אמשיך לעשות לך post review עד שתשתפר.

 

[nocgod]

אני חושב שאתה צריך לרדת מהעץ שלך

ועדיף במהרה.

 

[spiritus asper]

תצטרך לסנכרן את הגישה אליהם

למשל בעזרת המילה השמורה lock.
Multithreading הוא נושא מאוד רחב ועמוק שטומן בתוכו הרבה "סכנות", כך שצריך קצת להזהר לפני שמתחילים ליישם.
בתור התחלה, אפשר להתחיל לקרוא כאן: http://www.albahari.com/threading