threads ב c++

[viby]

threads ב c++

שלום למישהו יש מקור טוב ללימוד threads ב c++? תודה

 

[eyalbd]

בספר של ברוס אקל

יש פרק על threads. אני חושב שזה מצויין בשביל התחלה.

 

[roterl]

windows or linux ?

if for linux: http://www.tldp.org/FAQ/Threads-FAQ/ is a good start if you like , i can send you few demos i wrote. for windows it different and incompatiable with linux...

 

[אלדד28]

תגיד, שאלה לי

אם אתה מתמצא ביישום ה-threads ב-2.6 - ה-API נשאר אותו הדבר בדיוק, או שיש שינויים מ-pthreads?

 

[maorv]

הערה קטנה

הישום של תרדים בלינוקס לא נעשה בקרנל אלה בספריה glibc וכן עם המעבר ל nptl נעשו שינויים ב api.

 

[אלדד28]

הממממ.

הבנתי שב-2.6 ה-thread-ים הם חלק מהקרנל. בשבועיים האחרונים זה בערך כל מה שאני שומע. תוכל להפנות אותי בבקשה למקורות מהימנים בעניין? תודה!

 

[eyalbd]

יש תאימות מלאה לאחור

כלומר אם תיקח מערכת מבוססת 2.4 ותתקין בה 2.6 התוכניות אמורות לרוץ אותו דבר. מה שכן, נוספו פיצ'רים חדשים אבל כדי להנות מכולם תצטרך לשדרג את glibc. הנה תקציר השינויים שנעשו ב threads )לקוח מ post-halloween חפש בגוגל) :

Threading improvements. ~~~~~~~~~~~~~~~~~~~~~~~ - Ingo Molnar put a lot of work into threading improvements for 2.6. Some of the features of this work are: - Generic pid allocator (arbitrary number of PIDs with no slowdown, unified pidhash). - Thread Local Storage syscalls - sys_clone() enhancements (CLONE_SETTLS, CLONE_PARENT_SETTID, CLONE_SETTID, CLONE_CLEARTID, CLONE_DETACHED) - POSIX thread signals stuff (atomic signals, shared signals, etc.) - Per-CPU GDT - Threaded coredumping support - sys_exit() speedups (O(1) exit) - Generic, improved futexes, vcache - New, threading related ptrace features - exit/fork task cache - /proc updates for threading - API changes for threading. - Users should notice a significant speedup in basic thread operations. This is true to a lesser extent even for old-threading userspace libraries such as LinuxThreads. - Regressions should go to Ingo Molnar <[email protected]> and [email protected]. Regressions could happen in the area of signal handling and related threading semantics, plus coredumping. - Native Posix Threading Library (NPTL). Ulrich Drepper worked closely with Ingo on the threading enhancements, and developed a 1:1 model threading library. You can find out more about NPTL at http://people.redhat.com/drepper/nptl-design.pdf Process scheduler improvements. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - Another much talked about feature. Ingo Molnar reworked the process scheduler to use an O(1) algorithm. In operation, you should notice no changes with low loads, and increased scalability with large numbers of processes, especially on large SMP systems. - Scheduler is now Hyperthreading SMP aware and will disperse processes over physically different CPUs, instead of just over logical CPUs. - Robert Love wrote various utilities for changing behaviour of the scheduler (binding processes to CPUs etc). You can find these tools at http://tech9.net/rml/schedutils - The behavior of sched_yield() changed a lot. A task that uses this system call should now expect to sleep for possibly a very long time. Tasks that do not really desire to give up the processor for a while should probably not make heavy use of this function. Unfortunately, some GUI programs (like Open Office) do make excessive use of this call and under load their performance is poor. It seems this new 2.6 behavior is optimal but some user-space applications may need fixing. - The above applies to use of yield() in the kernel, too. - 2.6 adds system calls for manipulating a task's processor affinity: sched_getaffinity() and sched_setaffinity() - Regressions to [email protected] and [email protected] - Debian users who encounter effects such as skips in mp3 playback, jerky mouse movement may want to stop the X server from renicing itself to -10 You can alter this permanently with 'dpkg-reconfigure xserver-common'; if you elect not to have /etc/X11/Xwrapper.config managed by debconf, simply edit it directly. - Balancing of IRQs between multiple CPUs should be handled using the irqbalance (http://people.redhat.com/arjanv/irqbalance/) program. - David Mosberger maintains a webpage containing some current 'known gotchas' of the O(1) scheduler at http://www.hpl.hp.com/research/linux/kernel/o1.php​

 

[MotiAd]

חס ושלומלום..... (אלדד)

ה-API נשאר לחלוטין אותו הדבר רק המימוש ברמת הקרנל שונה. יש להם עכשיו הרבה בעיות BenchMark כדי לברר מי משני המימושים הוא יותר יעיל וזה מה שיקבע מה יהיה מימוש ה-threadים בעתיד.

 

[maorv]

שאלה

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

 

[MotiAd]

כן בהחלט...

דבר ראשון אינטואיטיבית. אין סיבה שזה יקרה. גם במוצרי מייקרוסופט זה ככה. זה שמערכת ההפעלה השתנתה הקריאה לפונקציות והפרמטרים לא השתנו. (לא תמיד נכון) אבל שתיים. באינטרנט, גם באתר של LinuxThreads (זה לא אתר אלא מידע על) זה נאמר. אני מצטער שאני לא יכול לספק לך מידע לגבי זה. (כתובת/קישור) גם בדיונים של POSIX ב-Austin Group ב-OpenGroup העניינים האלו נידונים.

 

[maorv]

ידוע אבל לא מסביר

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

 

[אלדד28]

יצא לי לדבר היום על קצה המזלג עם

מישהי מהעבודה שלי שהתלוננה על ההתנהגות עצמה שעושה להם בעיות, אבל לא על ה-API עצמו. גם אני שמעתי בלא מעט מקומות שה-API נשאר זהה. גם אם לא זה לא ממש נורא מבחינתי כי יש לנו WRAPPER-ים בכל מקרה לכל העסק. השאלה היותר חשובה מבחינתי היא מה ההבדלים מבחינה התנהגותית בין PT לבין NPTL, ואיזה השפעות יכולות להיות על האפליקציה שלי מהבחינה הזו. כמו כן, הבנתי ש-RH9 תומכת ב-NPTL למרות שהם עובדים עם הקרנל של 2.4 (אחרי שהם שינו אותו בעצמם), ומכיוון שאני מפתח על RH9 רציתי לדעת איזה בעיות עשויות להיות לי אם אני עובר ל-AS (או אחד אחר מהסדרה של RH), או אם אני עובר לדיסטרו אחר שמבוסס על 2.6. כל מידע מעניין בעניין יתקבל בשמחה. תודה!

 

[eyalbd]

מי יותר מוסמך מלינוס טורבלדס עצמו?

קרא בקישור אייל

 

[אלדד28]

זה די טבעי שהוא יגיד שה-API

מנסה להיות סטטי. השאלה היא האם הוא באמת סטטי. אני מניח שגם אם לא, השינויים הם מינוריים, ולכן אני לא מאוד מוטרד מזה. מה שיותר מטריד אותי זה ההתנהגות.

 

[maorv]

ציטוט קצר מיוצרי הספריה

Binary compatibility The new library should be maximally binary compatible with the Linux Threads implementation. Some semantic differences are unavoidable as the Linux Threads implementation is not POSIX compliant; the non-compliant functionality necessarily must change.​

 

[אלדד28]

יש מקום שמכיל את השינויים האלו,

או שאנחנו צריכים לנחש?

 

[maorv]

לכל היותר מה שמצאתי

The main incompatibilities are: Signal handling changes from per-thread signal handling to POSIX per process signal handling. This change will require changes in programs which depend on the non-conformance of the old implementation. getpid() now returns the same value in all threads the exec functions are implemented correctly: the exec'ed process gets the PID of the process. The parent of the multi-threaded application is only notified when the exec'ed process terminates. There is no manager thread​

ככל הידוע העבודה שנעשית על ה nptl עדיין לא גמורה (אין עדיין גירסה שנקראת יציבה) ולכן גם יהיה קשה למצוא מסמכים שמפרטים בנושא.

 

[roterl]

מצטער שנעלמתי... ../images/Emo13.gif

למייטב הבנתי לא צריכים להיות שינויים גדולים ב API, בהס"כ מדובר בתאימות POSIX ולפי מה שאני רואה מהשרשור עד כה, נראה שיש קצת שינויים, כשנראה הם בעיקר על ביצועים, ופחות על חוסר תאימות - כלומר - לפי הבנתי - רוב הפליקציות ימשיכו לעבוד, אבל לא בצורה אופטימלית. בכל מקרה כתבתי תוכנית שמריצה הרבה threads . התוכנית המקורית היא לצורך המחשת Bounded Buffer, אבל ניתן להשתמש בה לבדיקת ביצועיים בסיסיים במעט שינויים. אם יש עיניין, אני יעלה אותה לפה.