עכשיו אחרי שמימשתי LOCK על הנקודות שבהם מתבצע ENQUEUE או DEQUEUE הכל עובד יפה ואין יותר TIMEOUT, אך עדיין יש נקודות של עומס שרק קליינט אחד משתלט על התור ועובד איתו 2-3 שניות (שזה קריטי במערכת הזאת) בזמן שהאחרים מחכים.

אתה בעצם מציע לעשות לכל THREAD תור משלו?
מה הכוונה שאתה אומר שהסרבר יאסוף במחזוריות מכל התורים?

אם מדובר בביצוע אותו התפקיד, אז זה באמת יכול להיות יותר מורכב.
מה שכן, אתה יכול ליצור מערך של תורות שלכל אחד lock משל עצמו (per תא, נניח).
כל קליאנט יקבל id שיהיה בעצם התא במערך.
כשהקליאנט יתקשר מול הסרבר הוא ינעל את התא במערך, יוסיף לתור את העצם, ישחרר את המנעול וכן הלאה.
החוט של הסרבר יעבור סדרתית על המערך (מודולו האורך שלו),
כל פעם הוא ינסה לבצע try לתא במערך. אם הוא תפוס (ע"י חוט שמעדכן אותו מבחוץ) ימשיך הלאה. אחרת, יקח את האיבר הראשון מהתור וככה ימשיך הלאה.

בעצם יצא שלכל היותר חוט (קליאנט) יחכה לסרבר (main thread) בשביל שיוציא אובייקט (פעולה אטומית ביותר)
במקום שכל הת'רדים יגרמו ל-threshold מטורף כשכולם מנסים לתפוס את המנעול הראשי (כולל הסרבר עצמו).

השידור מהמכונות האלה נעשה בקוד EMBED לבקרה של חברת סימנס שכתבתי ב C++ ועובד מצויין (זאת מערכת שעובדת במספר מפעלים גדולים בארץ והוכיחה את עצמה). עד כאן, אין בעיות.

כל המידע עובר לסרבר שכתוב ב- C# ויושב על מחשב PC רגיל ותפקידו הוא להאזין ל12 המכונות הללו שכל מכונה מיוצגת ע"י THREAD נפרד וכל שורת מידע שהוא מקבל הוא מכניס לתור מרכזי.
כל הת'רדים עובדים בצורה זהה לחלוטין.

המידע שבתור נשלח ל WEB SERVICE ומשם נשלח ל DATABASE שנבנו ע"י חברת תוכנה אחרת ולא ממש בשליטתי.

הנה סרטוט שעשיתי בשביל להבהיר את הנושא:

תחשוב, ברגע שאתה שולח פאקטים במקביל ויש רק חוט אחד שעונה עליהם, יש פקטור עומס עיבוד של 1:12.
התור מתמלא יותר מהר מאשר הוא מספיק לעבד את הנתונים ולהתרוקן.

כמה ליבות יש ל-C# Server?
אם היו מבקשים ממני לממש מה שביקשת,
הייתי מממש מספר חוטי server בשרת הראשי כמספר הליבות,
כל חוט ידאג לחלק שונה במערך (מתוך 12 הערוצים), ובמקרה שנזקקים ל-load balance לאפשר איחוד בין חוטים או עבודה במקביל על אותו חלק במערך.
אסור שתראה שהקוד שלך כרגע בזמן עיכובים לא יאמץ את המעבד (כל הליבות) על פחות מ-100% שימוש מעבד/תקשורת מול ה-DB.

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

אכן יש עומס עבודה של 1:12 והמעבד שיושב על השרת דיי חלש, זה בסה"כ איזה PC מצ'וקמק עם 2 ליבות דיי חלשות, אולי נמליץ ללקוח לשדרג אותו למשהו יותר רציני (אני אבדוק את העומס על המעבד ביום ראשון מהמשרד).

אני לא יודע אם 12 חוטים ב SERVER יוכלו לעזור כי בסופו של דבר הכל נשלח ל WEB SERVICE בודד. אם נרצה לייעל לא נצטרך ליצור גם 12 חוטים לסרביס???

תוכל לפרט לי קצת יותר על האיחוד בין חוטים ל- LOAD BALANCE לא נתקלתי בזה אף פעם?

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

לא הבנת אותי אבל. לא 12 חוטים בסרבר - 2 יספיקו.
אני מדבר על 12 תאים בהם הקליאנטים יעדכנו את האינפורמציה שלהם.
בצורה זו לא יווצר מצב שקליאנט אחד ימתין לאחר, אלא לכל היותר קליאנט ימתין לסרבר שיסיים קריאת אובייקט מהתור שלו.

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

שוב, מעל ל-2 חוטים בשרת הראשי - אין שום סיבה להשתמש במעבד דו-ליבתי.
אתה יותר תבזבז זמן על סינכרוניזציה מאשר על טיפול בתורות.

אבל שימוש במערך של תורות באורך 12, אני בטוח שיאיץ את העבודה בערך פי 4 (גם אם יהיה לך main thread יחיד).

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

ד"א זה שכתוב שם THREAD POOL 13 זה צריך להיות 12 אפשר להתעלם.

בקשר לתקשורת עם ה-DB הכל עובר דרך WEBSERVICE שבנה מישהו אחר, אני לא מתעסק איתו מלבד קריאה לסרביס בשורה הזאת: int ret = mir.MachineMessage(

אבל הינה הקונספט לקוד:

https://rotter.name/User_files/nor/4b224c2c4d51be9a.txt

שים לב עכשיו איך כל מנעול תופס קטע קוד הרבה הרבה יותר אטומי (4-5 פעולות בממוצע במקום 100).
שים לב גם שכל סוקט (מה-12/13 אפשריים) שמכניס הודעה לתור תופס מנעול לוקאלי בלבד ולא תופס את כל התור כולו.

קראתי על LOCKS ומימשתי, כל העסק עובד (לצורך העניין בדקתי עכשיו ומשעה 8 בבוקר ועד עכשיו עברו בהצלחה 27,000 מחרוזות מידע מהמכונות ל DB).
אני רק מנסה לחשוב איך לייעל את זה כדי שת'רד אחד לא יתפוס את התור לאורך זמן, יש כמה רעיונות אבל אני לא בטוח מי מהם הכי יעיל.

זה שכל הזמן אנשים משתמשים ב-thread_pool, לא אומר שאנשים מתכנתים נכון בריבוי חוטים (ככה המרצה שלי טוען, מי אני שאתווכח איתו)
מעטים המתכנתים שבאמת יודעים לעבוד עם ריבוי חוטים, ואלה בדר"כ האנשים שעובדים באינטל, IBM וכו'.
ובכלל, זה שהקוד עובד לא אומר שהוא עובד נכון.

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