مشاكل التجزيء

Threading Issues

 

 

كما تعرفنا في الفصل السابق انه عملية الــfork() تقوم بخلق عملية جديدة ومنفصلة عن العملية الأم.

ولكن السؤال عندما يقوم  جزء (thread)  من عملية ما بمناداتها , هل ستقوم الــfork() بنسخ العملية ككل ؟ ام انها ستقوم بنسخ الجزء الذي قام بعملية المناداة؟

الجواب انه بعض من انظمة UNIX قامت بعمل نسختين , احداهما تقوم بنسخ كل اجزاء العملية والاخرى تقوم بنسخ الجزء الذي قام بعملية المناداة فقط.

 وكما تعرفنا بالسابق على عملية الــexec() , اذا قام جزء من برنامج بمناداة هذه العملية فإنها ستقوم باستبدال جميع الاجزاء القديمة التي ورثت عن العملية الأم.

بمعنى, اذا قام جزء بمناداة الــexec() مباشرة بعد مناداة الـــFork() فإنه لن يكون هناك فائدة من نسخ جميع الاجزاء للعملية الأم ,لأن الــexec() ستقوم باستبدال جميع اجزاء  العملية كلها.اما في حالة عدم استدعاء الــexec()  فإن ناتج عملية الــFork()  سيكون استنساخ اجزاء العملية (الأم) كلها.

 

 

 

 

Cancellation:

هو عبارة عن اجراء يتخذ عند الغاء جزء قبل ان يتمكن من انهاء عمله.

على سبيل المثال:

---اذا كان هنا عدة اجزاء يقومون بعملية بحث في قاعدة بيانات , وقد قام جزء بإعادة الناتج...اذن ليس هناك داعي ان تستمر باقي الاجزاء في عملية البحث,وبهذا يحدث لها انهاء مفاجىء قبل انهاء عملهم.

---مثال اخر على عملية الانهاء, انه عندما يقوم مستخدم بالتصفح على الانترنت فإن الصفحة المطلوبة تقوم باستخدام التجزيء موكلة عملية اظهار كل صورة على جزء  معين,فإذا قام المتصفح بالضغط على زر التوقف فإن باقي الاجزاء تتوقف بشكل مفاجىء عن عملها.

 

 

 

الجزء الهدف ( target Thread):

هو الجزء من عملية معينة الذي يتوقف قبل انهاء عمله وهذا التوقف يظهر في حالتين

 

 

1) Asynchronous cancellation :

عندما يقوم جزء بإيقاف جزء اخر مباشرة و  بشكل مفاجىء

 

 

 

2) Deferred cancellation:

 هو عندما يقوم (الجزء الهدف) بالتأكد بصفه مستمرة اذا ما كان يجب علية بالتوقف ام لا؟

ويتم تسمية النقاط التي يتأكد من خلالها الجزء الهدف هل يجب انه يلغى ام لا , بإسم cancellation points

وهذه العملية تعطيه فرصة التوقف بصورة طبيعية.

المشكلة الحقيقة عند انهاء الاجزاء تظهر عند انهاء جزء معين وهو في منتصف تحديث معلومات يقوم بمشاركتها مع اجزاء اخرى.في هذه الحالة فإنه على الأغلب ان نظام التشغيل سيقوم باسترجاع مصادر النظام من الجزء الهدف ولكن ليس جميعها!!! لهذا السبب القيام بعملية انهاء جزء معين ليس بالضروره  معناه انه سيتم  تحرير مصارد النظام.

 

 

---أما إذا قام  جزء بإعلان يفيد بإلغاء جزء اخر , ولكن عملية الإلغاء لن تتم إلا بعد ان يظهر الجزء الهدف اشارة انه يمكن ان يتم إلغاءه. وبهذا ممكن الغاء الجزء الهدف بشكل سليم.

-------------------------------------------------------------------------------------------------------

 

Signal handling:

تستخدم خاصية  الإشارة  (Signal  ) في نظام اليونكس لكي تقوم بتنبيه عملية معينة ان هناك حدث معين قد تم حدوثه. وهناك طريقتين لاستلام هذه الإشارات من قبل العملية:

Synchronous Signals  OR  Asynchronous Signals

هاتين الطرقتين يشتركون في هذه الخصائص:

1-    تظهر الإشاره بسبب  ظهور حدث معين.

2-     لابد من الإشارة ان ترسل لعملية معينة.

3-    عندما تستقبل الإشارة لابد ان تقوم العملية بمعالجتها.

 

 

 

 

 

 

أمثلة على الـــــ Synchronous Signals  :

هذا النوع من الإشارات يظهر عند الدخول غير المسموح به لجزء من الذاكرة أو عند القسمة على الصفر مثلا.

وبهذا اذا قام برنامج معين بحدث من هذا النوع, لابد ان تظهر إشارة , وفي هذا النوع من الإشارات , توصل الإشارة لنفس العملية التي تسببت بظهورها ولهذا السبب سميت بالـــــ Synchronous Signals.

 

 

أمثلة على الـــــAsynchronous Signals  :

في هذا النوع, السبب الذي يؤدي لظهور الإشارة يكون (خارج العملية) .

مثلا,عند الضغط على اوامر معينة مثل Control + c   وهذا يؤدي إلى إنهاء عملية ما بشكل مفاجئ.

 

 

 

أنواع معالجته الإشارات: Types of signal handling

هناك نوعان :

1-    المعالج الأصلي Default signal handler

2-    المعالج المعرف من قبل المستخدمUser defined signal Handler

كل إشارة بطبيعتها يكون لها معالج أصلي(  Default signal handler) يتم تشغيله من قبل الـــKernel , ولكن هذه الخاصية يمكن أن يقوم المستخدم بإلغائها و إعادة كتابتها بنفسه  وتسمى Userdefined signal Handler.

في البرامج التي من نوع Single thread  لا تظهر مشكلة تذكر في معالجة الإشارات , لأن الإشارة ترسل بشكل مباشر إلى العملية

 

ولكن ماذا يحدث لبرامج من نوع  Multithreaded؟

 

 

 

 

 

هناك عدة احتمالات:

1-    ان ترسل الإشارة للجزء الذي سبب ظهورها.

2-    ان ترسل الإشارة الى جميع أجزاء العملية.

3-    ان ترسل الإشارة لأجزاء معينة في العملية.

4-    تحديد لجزء واحد يقوم بعملية استقبال الإشارات.

وبالطبع تحديد طريقة إرسال الإشارة يعتمد على نوعية الإشارة نفسها.

 

 

على سبيل المثال,الإشارات من نوع Synchronous Signals لابد ان ترسل إلى الجزء الذي سبب ظهور الاشارة وليس لباقي أجزاء العملية.

أغلب أنظمة اليونكس تسمح للــ thread بأن يقوم باستقبال إشارات معينة ويحجب إشارات أخرى. ولهذا في بعض الأحيان يتم إرسال Asynchronous Signal  فقط للأجزاء التي لم تحجبها . وبما انه لابد من معالجة الإشارة فإنه يتم تسليمها لأول thread لم يقم بعملية الحجب.

في أنظمة الويندوز,يتم معالجة الاشارات عن طريق  الـــAPCs (Asynchronous procedure calls).

حيث تقوم هذه الخاصية بالسماح للـــuser thread  بتحديد function   ليتم مناداتها عندما يستلم جزء معين التنبيه لظهور حدث.ويتم التسليم لجزء معين بدلا من التسليم لكل العملية.

 

                                               -----------------------------------------------------------------------------------------------------------

 

 

 

 

Thread Pools:

 

كبداية لتوضيح هذا المفهوم, لنأخذ مثال عند تصفح الانترنت ونقوم بإرسال طلب للسيرفر التابع لموقع معين فإنه من الأفضل ان يقوم السيرفر بخلق جزء جديد بدلا من إنشاء عملية جديدة لتنفيذ هذا الطلب. ولكن هذه النظرية لا تخلو من المشاكل أولها :

<!--[if !supportLists]-->1- الوقت المستغرق لإنشاء جزء جديد ليقوم بتنفيذ العملية المطلوبة

<!--[if !supportLists]-->2-  عدم القدرة على تحديد عدد الأجزاء الجديدة المسموح بإنشائها وعلى هذا سيتشكل ضغط كبير على موارد النظام كالذاكرة ووحده المعالجة المركزية.

ولحل هذه المشاكل وجد مفهوم مسابح الأجزاء Thread Pools.

 

 

وهنا يأتي تعريف هذا المفهوم:

هو عبارة عن خلق عدد من الأجزاء ووضعها في وعاء حيث ينتظرون وقت تشغيلهم.

وبهذا عندما يستقبل السيرفر طلب ما, فإنه يقوم بإيقاظ أحد هذه الأجزاء وإعطاءه مهمة تنفيذ الطلب.وما ان يقوم هذا الجزء بإنهاء عمله لأنه يعود إلى الوعاء وينتظر للقيام بعمل اخر.وفي حالة ان كل الأجزاء في الوعاء كانت مشغولة  فإن السيرفر ينتظر احدهم إلى ان يصبح متوفرا .

 

 

 

ومن هذا نخلص إلى فوائد أوعية الأجزاء:

<!--[if !supportLists]-->1-   سرعة تنفيذ الطلب من قبل الأجزاء الموجودة في الوعاء مقارنة مع الأجزاء التي تنشأ عند الطلب.

<!--[if !supportLists]-->2-   الوعاء يقوم بتحديد عدد الأجزاء المسموح بإنشائها وبهذا لا يتشكل ضغط على موارد النظام مع كثرة الطلبات.

 

طرق تحديد عدد الأجزاء المسموح بها:

يتحكم بها عدة أشياء منها عدد الـــCPUs المتوفر في النظام , حجم الذاكرة وعدد الطلبات  المتوقعة من المستخدم.

وهناك أنظمة ذكية والتي تقوم بدورها بتحديد العدد المطلوب تبعا للاستخدام وهذا ينتج أوعية أصغر وبالطبع يقوم بتوفير جزء من الذاكرة المستخدمة عندما يكون الضغط قليل على النظام.

 

 

 

 

Thread –Specific Data:

 

فكرة وجود الأجزاء التابعين لعملية معينة تسمح لهم بمشاركة معلومات هذه العملية ولكن في بعض الأحيان قد يحتاج كل جزء نسخته الخاصة فيه من هذه المعلومات حيث تسمى هذه المعلومات بــــthread –Specific data .

 

 

 

 

 

 

بالنسبة للبرامج المتعددة الأجزاء هنا مشكلة التواصل بين قلب النظام والـــthread library والتي تتطلب من النظام بالقيام بتحديد عدد من أجزاء  قلب النظام للقيام بعملية الارتباط.

هناك عدد من أنظمة التشغيل تقوم بوضع بيانات تتوسط بين أجزاء المستخدم و أجزاء قلب النظام. هذه البيانات والتي تعرف بالــLightweight process أو LWP عبارة عن معالج  خيالي والذي يقوم البرنامج الذي يكون تحت التشغيل بجدولة جزء المستخدم عليه .

وبهذا كل LWP  تكون مرتبطة مع جزء من قلب النظام.

§        قد يتطلب برنامج معين اي عدد من الــLWP لكي يتم تشغيله بطريقة صحيحة.

على سبيل المثال: في حالة وجود برنامج يعمل على معالج واحد , اذن لن يتم تشغيل أكثر من جزء في المرة الواحدة ولن يحتاج إلى أكثر من LWP واحد.

Scheduler Activation

طريقة للتواصل بين الـUser thread library وقلب النظام

طريقة عمله:

يقوم قلب النظام بتزويد البرنامج بمجموعة من الــLWP وعندها يستطيع البرنامج بالقيام بجدولة أجزاء المستخدم على المعالج الخيالي .

Upcall:  هي الحالة المعروفة عندما يقوم قلب النظام بإعلام برنامج معين بظهور حدث جديد.

طريقة عمل هذه الخاصية:

تتم معالجة التنبيهات القادمة من قلب النظام من قبل Upcall handler والتي لابد من ان تعمل على المعالج الخيالي.

مثال على حدوث عملية Upcall: عندما يقوم قلب الناظم بالتنبيه ان هناك جزء معين سوف يتم إيقافه , في هذه الحالة سيتم تعيين معالج  خيالي اخر لهذا البرنامج.