‫תגובות לפוסט: "try, catch, write"‬ http://heblog.ronklein.co.il ‫הבלוג של רון קליין, תכנות, OOP ועוד עניינים‬ Tue, 09 Mar 2010 21:33:21 -0700 http://wordpress.org/?v=2.9.1 hourly 1 ‫תגובה לפוסט: "log4net – המדריך למלגלג (חלק 3 – למצוא viewer נורמלי)" מאת "יעל"‬ http://heblog.ronklein.co.il/2009/12/log4net-part3/comment-page-1/#comment-2304 ‫יעל‬ Tue, 09 Mar 2010 21:33:21 +0000 http://heblog.ronklein.co.il/?p=99#comment-2304 ‫איך למען ה' אני פותחת את הקובץ לוג שנוצר לי????‬

איך למען ה' אני פותחת את הקובץ לוג שנוצר לי????

]]> ‫תגובה לפוסט: "תור מקבילי – Concurrent Queue" מאת "Liran"‬ http://heblog.ronklein.co.il/2009/06/concurrent-queue/comment-page-1/#comment-2293 ‫Liran‬ Sat, 16 Jan 2010 15:07:34 +0000 http://www.ronklein.co.il/qwe/?p=4#comment-2293 ‫בתרחישים מהסוג הזה לא בהכרח חייבים להשתמש בתור סטנדרטי, אלא במקום זה אפשר גם לבדוק מימושים אלטרנטיבים שפותרים את בעיית ה-single producer/consumer בצורה יעילה יותר. למשל: http://www.bluebytesoftware.com/blog/2009/10/05/FastSynchronizationBetweenASingleProducerAndSingleConsumer.aspx בפוסט יש אנלוגיה די מבלבלת לשימוש במבנה הנתונים "תור" (שמירת נתונים במבנה FIFO), לבין הבטחת סדר נעילות של ת'רדים על אובייקט מסויים. בהקשר של fairness, לדעתי דוגמה טובה יותר תהיה ההבדל בין מימוש SpinLock "רגיל" לצד מימוש של Queue Lock כלשהו, למשל MCS Lock (הראשון גורם לכך שברגע שהנעילה משתחררת כל הת'רדים "נלחמים" על תפיסת הנעילה, בעוד שהשני דואג לכך שרק ת'רד מסויים יזכה לראות שהנעילה השתחררה והוא בוודאות יהיה זה שיזכה לבצע את הנעילה)‬

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

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

]]> ‫תגובה לפוסט: "From lock to abstract locker" מאת "רון קליין"‬ http://heblog.ronklein.co.il/2010/01/from-lock-to-abstract-locker/comment-page-1/#comment-2292 ‫רון קליין‬ Wed, 06 Jan 2010 21:18:27 +0000 http://heblog.ronklein.co.il/?p=214#comment-2292 ‫<a href="#comment-2291" rel="nofollow">@לירן</a>, אני מסכים איתך שהאבסטרקציה כאן מורידה במשהו מהקריאות של הקוד. למעשה אני חושב כבר על הפוסט שיסביר את הרעיון של נעילה באמצעות decorator, שזה נראה לי כרגע פתרון קצת יותר אלגנטי. צ'ירס!‬

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

]]> ‫תגובה לפוסט: "From lock to abstract locker" מאת "Liran"‬ http://heblog.ronklein.co.il/2010/01/from-lock-to-abstract-locker/comment-page-1/#comment-2291 ‫Liran‬ Wed, 06 Jan 2010 19:32:16 +0000 http://heblog.ronklein.co.il/?p=214#comment-2291 ‫למרות שהרעיון יפה, אני לא חושב שיש לאבסטרקטציה הזאת הרבה טעם משום שהעלות של תפיסת נעילה (ללא contentions) הוא מינימלי, כך שהוספת עוד שכבת אבסטרקציה לקוד נראית מעט מיותרת (גורמת לקוד להראות מסובך יותר ללא צורך). ובנוגע ל-SpinLock, מעטים הם המקרים שבאמת מצדיקים שימוש בו. בדרך כלל בשימושי "High Level" תקבל ביצועים טובים יותר בשימוש עם אובייקטי קרנל (שעליהם מתבסס Monitor).‬

למרות שהרעיון יפה, אני לא חושב שיש לאבסטרקטציה הזאת הרבה טעם משום שהעלות של תפיסת נעילה (ללא contentions) הוא מינימלי, כך שהוספת עוד שכבת אבסטרקציה לקוד נראית מעט מיותרת (גורמת לקוד להראות מסובך יותר ללא צורך).
ובנוגע ל-SpinLock, מעטים הם המקרים שבאמת מצדיקים שימוש בו. בדרך כלל בשימושי "High Level" תקבל ביצועים טובים יותר בשימוש עם אובייקטי קרנל (שעליהם מתבסס Monitor).

]]> ‫תגובה לפוסט: "System.String is UTF16" מאת "Arnon Rotem-Gal-Oz"‬ http://heblog.ronklein.co.il/2009/09/system-string-is-utf16/comment-page-1/#comment-2276 ‫Arnon Rotem-Gal-Oz‬ Sun, 27 Sep 2009 12:06:29 +0000 http://heblog.ronklein.co.il/?p=50#comment-2276 ‫אותך לקורט :)‬

אותך לקורט :)

]]> ‫תגובה לפוסט: "תור מקבילי – Concurrent Queue" מאת "רון קליין"‬ http://heblog.ronklein.co.il/2009/06/concurrent-queue/comment-page-1/#comment-3 ‫רון קליין‬ Sun, 09 Aug 2009 04:05:04 +0000 http://www.ronklein.co.il/qwe/?p=4#comment-3 ‫לירן, התרחיש המקורי הוא UDP Server שמאזין לפורט מסויים (וזה יכול להיות גם TCP), שמקבל הרבה בקשות. רציתי לקבל את הבקשה בזמן קצר ככל האפשר (כדי לחזור ולהאזין לבקשה הבאה), ולטפל בבקשות לפי סדר ההגעה שלהן. נכון, אין לי שליטה על סדר ההגעה, אבל רציתי שסדר הטיפול בבקשות ישקף (ככל האפשר) את סדר ההגעה.‬

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

]]> ‫תגובה לפוסט: "תור מקבילי – Concurrent Queue" מאת "Liran Chen"‬ http://heblog.ronklein.co.il/2009/06/concurrent-queue/comment-page-1/#comment-2 ‫Liran Chen‬ Thu, 06 Aug 2009 19:12:42 +0000 http://www.ronklein.co.il/qwe/?p=4#comment-2 ‫הבעיה שאתה מתאר לא בלעדית ל-lock'ים. אותו דבר יכול לקרות למשל כשאתה עובד עם wait handle'ים למשל. הבעיה התיאורתית, היא שנניח ויש לך autoResetEvent ות'רד שמחכה לקבל עליו signal. אבל יתכן שבכל פעם שעושים set ל-event יגיע ת'רד אחר "שיגנוב" לו את ה-signal ויגרום ל-reset של ה-event. כך שאותו ת'רד שחיכה כל הזמן אף פעם לא מצליח לקבל signal בפועל, אין באמת משמעות לזה שכן שומרים על הסדר/לא שומרים על הסדר. כי אחרי הכל, ברגע שאתה עובד מול מספרים ת'רדים, אז בין כה וכה סדר העבודה/הגעה לא מובטח, והניסיון להבטיח סדרים יכול להיות מיותר מעצם זה שאף אחד לא מבטיח לך שום דבר לגבי חלוקת הזמן בין הת'רדים השונים, כך שאין מה להסתמך/לבנות על זה, הרי אין לנו שליטה על זה בכל מקרה‬

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

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

]]>