האם זה תכנות נכון?

[הצלוי]

האם זה תכנות נכון?

אני צריך לכתוב בג'אווה שתי מחלקות- של פילוסוף ושל מקל סיני (אל תשאלו...)

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

 

[vinney]

בעיית הפילוסופים הסועדים קוראים לזה

וזה בא לתרגל mutexים. אני לא יודע איך עושים את זה בג'אווה (נראה לי יש אובייקט מוכן לזה), אבל זה הרעיון הכללי. בגדול מה שאתה מתאר יכול להתאים להגדרה של mutex לצורך העניין, אבל לשאלתך אם זה תכנות נכון, אז לא, זה לא.

 

[הצלוי]

mutex?...

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

 

[DadleFish]

הממממ

mutex הוא אובייקט שהוא mutually exclusive בין שני תהליכים שונים - כלומר, כשאחד משתמש בו, השני לא יכול להשתמש בו. אם אני לא טועה, ב-java אתה יכול להגדיר אובייקט בתור synchronized ואז זה הופך אותו אוטומטית ל-mutex. בכל אופן, ברמה הכי פשוטה מה שאתה צריך זה באמת לדאוג לשמור בתוך המקל שלך את הפילוסוף הנוכחי, ולא לתת לפילוסוף אחר לשחרר אותו.

 

[הצלוי]

כן, אני משתמש בsynchronized

אז מבחינת design, זה בסדר לשמור בכל פילוסוף קישור לשני מקלות, ובכל מקל קישור לפילוסוף הנוכחי שמחזיק אותו? והאם זה בכלל אפשרי? כי בינתיים זה לא מתקמפל (מן הסתם אני לא יכול להשתמש בפילוסוף בתור מקל סיני לפני שיצרתי מחלקה של פילוסוף וכנ"ל לגבי להשתמש במקל סיני בפילוסוף לפני שיצרתי מחלקה של מקל סיני) ואני מנסה לחשוב על דרך לעקוף את הבעיה הזאת..

 

[vinney]

תמספר אותם

 

[הצלוי]

למספר את מה?

הבעיה היא שהוא לא רואה את המחלקה. אני כותב במחלקה Fork (לא רציתי לקרוא לזה ChineseStick...

): private Philosopher p ומופיעה לי שגיאת ריצה שאומרת שאין מחלקה Philosopher... ואני לא יכול לקמפל את Philosopher כי שם כתוב לי private Fork f!! זה כמו בעיית הביצה והתרנגולת...

 

[DadleFish]

את הפילוסופים כמובן

תחזיק int במקל, ולא את המחלקה של הפילוסוף עצמה.

 

[הצלוי]

Ohhh....../images/Emo163.gif

 

[vinney]

../images/Emo5.gifסתם תהליכים???

הבעיה הזאת נולדה להדגים את בעיית מניעה הדדית, אין לה שום משמעות אם אתה לא מתייחס לנושא הזה

עובדה אבל שאתה כן מתייחס לנושא הזה (אפילו בלי לדעת את השם הרשמי), כך שאני רגוע

 

[הצלוי]

אל תדאג../images/Emo13.gif

ברור שאני מתייחס לזה.. איך אפשר להשתמש בתהליכים בלי להתייחס לבעיות סינכרון והתחלקות במשאבים... mutex זה השם הרשמי?

אני קראתי לזה שיתוף משאבים.. או synchronized בג'אווה...

 

[DadleFish]

JAVA מסתירה ממך די הרבה

מההתלבטויות בעניינים האלו של השיתוף - לטוב ולרע.

 

[הצלוי]

מה למשל?

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

 

[הצלוי]

*דומות

 

[vinney]

לא בדיוק

גם בעדה כל נושא ניהול תהליכים מוסתר. ללמוד את זה באמת אפשר רק בC/CPP.

 

[DadleFish]

למשל,

ב-JAVA אין ריבוי של אובייקטי סינכרון - ב-WIN32 למשל יש EVENT, MUTEX, SEMAPHORE, CRITICAL SECTION ועוד. ב-JAVA אין את העושר הזה, מסיבות שונות.

 

[הצלוי]

עכשיו אתה חייב לומר לי מה ההבדל

בין SEMAPHORE, MUTEX, EVENT ו CRITICAL SECTION.....

 

[voguemaster]

הבדלים

רק בגלל שאני נורא עייף היום בבוקר

: 1. EVENT - כשמו כן הוא, פשוט אירוע. ע"י שימוש ב-EVENT, תהליכון (המצאתי מילה חדשה ל-thread

) יכול לשלוח "הודעה" ל-thread אחר (או כמה) כדי להודיע להם או לסמן להם שמשהו קרה. דוגמא פשוטה: יש לך thread אחד שצריך לישון עד ששולחים לו הודעה כלשהי ואז הוא מעבד אותה. ה-thread ששולח לו הודעה צריך מנגנון להעביר את אותה הודעה (שגם יעיר את השני). הנה לך

2. MUTEX - כבר הוזכר כאן. אובייקט שרק thread אחד יכול להיות הבעלים שלו. כשרוצים גישה למשאב שמשותף לכמה תהליכונים (

) צריך לסנכרן את הגישה אליהם עם אובייקט כזה. שים לב שבחלונות MUTEX הוא אובייקט ברמת הקרנל שגם מאפשר סינכרון בין פרוססים, בלינוקס הוא שקול ל-CRITICAL SECTION של חלונות ובג'אווה הוא בערך החיה היחידה שיש. כל מחלקה, מתודה או משתנה שהוא synchronized למעשה מוגנים ב-MUTEX. נחמד לא ?

3. SEMAPHORE - מזכיר בסגנון העבודה שלו MUTEX אבל הוא טיפה שונה. הוא מאפשר ליותר מתהליכון אחד לגשת אליו. למעשה יש לו מונה של כמה threadים נעלו אותו. לא לבלבל עם MUTEX רקורסיבי שאותו thread אחד יכול לנעול כמה פעמים. בלינוקס יש שני סוגים של SEMAPHORES, אחד ל-threads ואחד ל-processes. רק בלבול יוצא מכל המושגים האלה תאמין לי... 4. CRITICAL SECTION - האובייקט הפשוט ביותר (שמוגדר בתור מבנה גלובלי בתוכנית בד"כ, בצורה כזו או אחרת). מתפקד כמו MUTEX אלא שהוא אובייקט ברמת התוכנית ולא הקרנל (יש לזה כמה חסרונות, וקצת יתרונות). זהה מבחינת האופי והשימוש כמעט לגמרי ל-MUTEX בלינוקס. עוד ?

 

[הצלוי]

סבבה../images/Emo13.gif

אבל.. מה ההבדל אם האובייקט ברמת התוכנית או ברמת הקרנל? (בקשר לCRITICAL SECTION)

 

[vinney]

גישה

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