Browse by Tags
All Tags »
DEV »
Multithreading (
RSS)
שימוש ב-Object Pools בסביבה דוט-נטית יכול לתרום לנו בעיקר משתי בחינות: א) הורדת זמן האתחול עבור אובייקטים "כבדים" שעלולים לקחת זמן רב עד שישלימו את האתחול הראשוני שלהם, ב) הורדת כמות וקצב ההקצאות הדינאמיות שהתוכנית שלנו מבצעת, ועל ידי כך להוריד את ה-Latency שה-GC עשוי להוסיף לנו ב-Collection'ים עתידיים. עם זאת, ראוי לציין שבתרחישים מסויימים שימוש ב-Object Pools יכול דווקא לפגוע בביצועים. מאחר ובסביבות מנוהלת (CLR, JVM וכו'..) הזמן שלוקח לנו להקצות זכרון לאובייקט יהיה בדרך כלל מהיר...
בדיון שעלה לאחרונה בפורום דוט-נט בתפוז, עלתה השאלה "באיזה פרימיטיב סנכרון ה-CLR משתמש כאשר אנחנו קוראים ל-Monitor.Enter?". האם נוצר Mutex לטובת העניין? אולי Event? ואולי בכלל מדובר בפרימטיב שרץ גם ב-User Mode כגון CriticalSection? מתברר שקיימת איזשהיא אי-בהירות בנושא הזה, כך שהפוסט הזה ידגים איך ניתן לברור את התשובה לשאלה בכלים העומדים לרשותנו. לפני קרוב לשנה פרסמתי פוסט קצר שתיאר בקווים כללים את האופן בו מנגנון הנעילות של ה-CLR עובד. בקצרה, הרעיון הוא שמתוך כל בלוק Header של אובייקט דוט...
אחת התורות הנסתרות בפיתוח מקבילי היא השאלה "בכמה ת'רדים צריך להשתמש כדי להגיע לניצול מירבי של החומרה העומדת לרשותנו?". יש שיגידו שמספר הת'רדים צריך להיות כמספר המעבדים, או כמספר המעבדים +1, או אולי בכלל פי 2 ממספר המעבדים. הסיבה שיש כל כך הרבה תשובות לשאלה, היא פשוט בגלל הסיבה שעבור כל תרחיש מסויים, תתאים תשובה אחרת (לכל אפליקציה יש אופי שונה, למשל האם היא מוגבלת על ידי ה-CPU או ה-IO?). אבל בכל אופן, תמיד הנוסחאות האלה מתבססות באיזשהיא צורה על מספר המעבדים הזמינים לנו (סך הכל, אנחנו...
בתקופה האחרונה שמתי לב שהנושא של False Sharing עולה לעתים די קרובות בבלוגים שמפרסמים פוסטים המסבירים במה בעצם מדובר ובאיך אפשר להמנע מהתופעה. כך שכמובן שהגיע הזמן שאתייחס בעצמי לנושא החשוב אך חמקמק הזה. אבל קודם כל, נסביר בקצרה במה בעצם מדובר ובאיפה טמונה הבעיה. אחד הנושאים הרגישים בפיתוח קוד מקבילי הוא הגישה לזיכרון המשותף למספר Thread'ים שונים. (כדי שנשאר ממוקדים בנושא הפוסט, אני אתעלם לרגע מבעיות העלולות להגרם כתוצאה מ-Instruction Reordering או אופטימיזציות אחרות שמבוצעות ברמת הקומפיילר או...
לפני 3 חודשים כתבתי פוסט קצר שהציע דרך להקל על עבודת ה-Debug תחת Multithreaded Environments. במקום להתחיל לקבוע Breakpoint'ים עם פילטרים שיגרמו רק לת'רד מסויים להעצר בהם, הצעתי להגדיר Breakpoint רגיל וברגע שנעצרים בו, פשוט לגשת לפאנל ה-Threads ולהקפיא את כל שאר הת'רדים הקיימים (עניין של Select All והקלקה על Freeze). לאחרונה John Robbins פרסם בבלוג שלו פוסט עם דוגמה לפקודת מאקרו שמקפיאה באופן אוטומטי את כל הת'רדים חוץ מהפעיל. למעשה, אוטומטיזציה של הפוסט הקודם שלי. כך שאפשר לחסוך אפילו...
כשזה מגיע לתכנות מקבילי, משימה נפוצה למדי היא להשתמש בת'רד נפרד בתוכנית שיטפל בכל מיני קלטים/בקשות שהתוכנית שלנו מקבלת. מה שקורה בדרך כלל הוא שבזמן היצירה של הת'רד, מכניסים אותו לפונקציה עם לולאה אינסופית, ובתוך הלולאה מחכים לקבל Signal על כך ש"יש עבודה" לעשות. בצורה גסה, התבנית הבסיסית נראית כך: AutoResetEvent m_event = new AutoResetEvent ( false ); private void WorkCycles() { while ( true ) { // wait for a signal m_event.WaitOne(); // do work.. } } שימוש ב- AutoResetEvent מאוד...
לכל ת'רד שרץ תחת מערכת ההפעלה יש עדיפות, שיכולה להקבע על ידי.. כל אחד. אלה יכולים להיות אתם, המפתחים, שדואגים להעניק עדיפות מיוחדת לת'רד שיצרת ם, או שאולי זה יכול גם להיות משתמש שובב, שקם בבוקר והחליט לפתוח את ה-Task Manager ולהכניס תהליך שלם לעדיפות Realtime (למעשה, לקבוע את ה-Priority Class של התהליך, שבתורו משפיע על העדיפות שכל ת'רד באותו תהליך מ קבל). בתיאוריה, כיול ומענק חכם של עדיפויות יכול להביא לשיפור בתגובתיות ובביצועים של המערכת. אולם, במציאות.. סביר להניח שלא רק שהמשחקים האלה...
בדוט-נט קיים מנגנון סנכרון אובייקטים מובנה. ובין אם אנחנו מודעים לזה או לא, אנחנו משתמשים בו בכל פעם שאנחנו באים לסנכרן קטעי קוד באפליקציה שלנו. המשמעות היא שאנחנו לא צריכים לגשת לאובייקטי סנכרון מובנים של מערכת ההפעלה, בכל פעם שאנחנו רוצים לעשות lock קטן בקוד. מה שמקנה לנו יתרון בביצועים בהשוואה לשימוש באובייקטי סנכרון כגון Mutex או Semaphore (במקרה שלנו, אובייקט הקרנל היחיד בו משתמשים הוא Event). עבור כל אובייקט שקיים אצלנו באפליקציה, קיים גם SyncBlock שמשוייך אליו. אותו אובייקט SyncBlock אחראי...
דבר אחד שימושי בדוט-נט הוא התמיכה הטבעית הקיימת ל-Event'ים. כדי ליצור אירוע למחלקה שלנו, כל מה שעלינו לעשות הוא להגדיר Event חדש בעזרת ה-Delegate המתאים, וזהו זה. שימו לב שאפילו לא היינו צריכים לכתוב Accessors כלשהם, מאחר וכברירת מחדל, אלא אם כן לא הגדרנו אחרת, הקומפיילר יחולל כבר Accessor'ים משלו שידאגו לנהל עבורנו את הרישומים עבור האירוע שהגדרנו. זוהי נקודה שהרבה פעמים לוקחים כמובן מאליו, ולא מפנים אליה תשומת לב מיוחדת, ולמרות זאת, מסתתרת מאחוריה משמעות קריטית כש-Multithreading נכנס לתמונה...
כל מי שאי פעם ניסה לדבג קוד שרץ תחת כמה ת'רדים בו זמנית, נתקל כנראה בתופעה המציקה שברגע שמבצעים Step Inside וכו', בדיוק כשאתם באמצע הדיבאגינג .. הדיבאגר לוקח אתכם בחזרה 200 שורות קוד לאחור, בפרוייקט אחר בכלל, חותך את חוט המחשבה שלכם בדרך, ובעצם מחזיר אתכם בחזרה ל breakpoint המקורי שהגדרתם. למה? כי פתאום ת'רד אחר בכלל הגיע לאותו ה breakpoint. הצורה בה רוב האנשים מתמודדים עם הבעיה, היא דרך כל מיני "משחקים" עם הדיבאגר. למשל לבטל את ה breakpoint ברגע שנעצרנו בו בפעם הראשונה .. לזכור...