‫תגובות לפוסט: "תור מקבילי – Concurrent Queue"‬

‫מאת: Liran‬

‫Liran‬ — Sat, 16 Jan 2010 15:07:34 +0000

בתרחישים מהסוג הזה לא בהכרח חייבים להשתמש בתור סטנדרטי, אלא במקום זה אפשר גם לבדוק מימושים אלטרנטיבים שפותרים את בעיית ה-single producer/consumer בצורה יעילה יותר. למשל: http://www.bluebytesoftware.com/blog/2009/10/05/FastSynchronizationBetweenASingleProducerAndSingleConsumer.aspx

בפוסט יש אנלוגיה די מבלבלת לשימוש במבנה הנתונים "תור" (שמירת נתונים במבנה FIFO), לבין הבטחת סדר נעילות של ת'רדים על אובייקט מסויים. בהקשר של fairness, לדעתי דוגמה טובה יותר תהיה ההבדל בין מימוש SpinLock "רגיל" לצד מימוש של Queue Lock כלשהו, למשל MCS Lock (הראשון גורם לכך שברגע שהנעילה משתחררת כל הת'רדים "נלחמים" על תפיסת הנעילה, בעוד שהשני דואג לכך שרק ת'רד מסויים יזכה לראות שהנעילה השתחררה והוא בוודאות יהיה זה שיזכה לבצע את הנעילה)

‫מאת: רון קליין‬

‫רון קליין‬ — Sun, 09 Aug 2009 04:05:04 +0000

לירן, התרחיש המקורי הוא UDP Server שמאזין לפורט מסויים (וזה יכול להיות גם TCP), שמקבל הרבה בקשות. רציתי לקבל את הבקשה בזמן קצר ככל האפשר (כדי לחזור ולהאזין לבקשה הבאה), ולטפל בבקשות לפי סדר ההגעה שלהן. נכון, אין לי שליטה על סדר ההגעה, אבל רציתי שסדר הטיפול בבקשות ישקף (ככל האפשר) את סדר ההגעה.

‫מאת: Liran Chen‬

‫Liran Chen‬ — Thu, 06 Aug 2009 19:12:42 +0000

הבעיה שאתה מתאר לא בלעדית ל-lock'ים. אותו דבר יכול לקרות למשל כשאתה עובד עם wait handle'ים למשל. הבעיה התיאורתית, היא שנניח ויש לך autoResetEvent ות'רד שמחכה לקבל עליו signal. אבל יתכן שבכל פעם שעושים set ל-event יגיע ת'רד אחר "שיגנוב" לו את ה-signal ויגרום ל-reset של ה-event. כך שאותו ת'רד שחיכה כל הזמן אף פעם לא מצליח לקבל signal

בפועל, אין באמת משמעות לזה שכן שומרים על הסדר/לא שומרים על הסדר. כי אחרי הכל, ברגע שאתה עובד מול מספרים ת'רדים, אז בין כה וכה סדר העבודה/הגעה לא מובטח, והניסיון להבטיח סדרים יכול להיות מיותר מעצם זה שאף אחד לא מבטיח לך שום דבר לגבי חלוקת הזמן בין הת'רדים השונים, כך שאין מה להסתמך/לבנות על זה, הרי אין לנו שליטה על זה בכל מקרה