• Like
Deadlock
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

Deadlock

  • 10,117 views
Published

 

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
No Downloads

Views

Total Views
10,117
On SlideShare
0
From Embeds
0
Number of Embeds
0

Actions

Shares
Downloads
272
Comments
3
Likes
6

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. CHAPTER 7 الفصل السابــــــــــــــــــع DEADLOCKS الجمــــــــــــــــــــــود
  • 2. مقدمــــــــــــــــــــــــة
    • في بيئة متعدد البرمجة، العديد من العمليات يتنافس على عدد محدود من المصادر (resources) .
    • العملية تطلب المصادر، إذا كانت هذه المصادر غير متوفرة في هذا الوقت، عندها لابد أن تدخل العملية في حالة انتظار (wait) .
    • ربما يحدث أن العمليات لا تغير من حالتها مرة أخرى لأن المصادرة محجوزة لعمليات أخري هي الاخرى في حالة انتظار (wait) .
    • هذا ما يطلق عليه الجمود ( Deadlock )
    • و هذا تم الحديث عنه في الفصل السادس عندما تكلمنا عن السيمافور .
  • 3. مقدمــــــــــــــــــــــــة
    • لعل أفضل شرح لعملية الجمود (deadlock) نستطيع أن نتخيله من قانون صادق عليه مجلس كانساس التشريعي في أوائل هذا القرنِ . الذي ينص على :
    • ” when two trains approach each other at a crossing, both shall come to a full stop and neither shall start up again until the other has gone “
    • في هذا الفصل سوف نستعرض بعض الطرق التي تتخلص من مشكلة الجمود (deadlock) .
  • 4. 7.1 System Model
    • النظام يتكون من عدد محدود من المصادر موزعة على عدد من العمليات التي تطلبها بإلحاح .
    • المصادر مقسمة على العديد من الأنواع، كل قسم يتكون من بعض الأعداد من الحالات المماثلة .
    • من أمثلة المصادر :
    • Memory space, CPU cycles, files, and I/O devices (such as printers, tape drives, disk drives) .
    • مثلاً إذا كان النظام يملك اثنين من الـ CPU ، إذاً المصدر CPU له حالتان (two instances) .
  • 5. 7.1 System Model
    • Deadlock may involve ( تضمن ) the same resource types
    • مثال :-
    • بفرض أن النظام به ثلاثة من tape drives و بفرض وجود ثلاثة من العمليات ، كل واحدة منهم تحجز واحد من tape drives الثلاثة . ممكن ان تصبح العمليات الثلاثة في حلة جمود إذا طلبت كل واحدة من العمليات الثلاثة tape drive اخر . لأن كل واحدة سوف تنظر إحلال tape drive .
  • 6. 7.1 System Model
    • Deadlock may involve ( تضمن ) different resource types
    • مثال :-
    • بفرض أن النظام به طابعة واحدة فقط و tape drive واحد فقط .
    • بفرض أن العملية P i تحجز الـ tape drive و أن العملية P j تحجز الطابعة .
    • إذا طلبت العملية P i الطابعة و العملية P j طلبت الـ tape drive هنا يحدث الجمود .
  • 7. 7.2 Deadlock Characterization وصف ( تمثيل ) الجمود
    • يجب أن يكون واضحاً جداً أن عملية الجمود مكروه جداً .
    • في عملية الجمود، العمليات لا تنهي تنفيذها مطلقاً و مصادر النظام تظل مربوطة ( محجوزة ) و تمنع jobs اخرى منعاً باتاً من البدء
  • 8. 7.2 Deadlock Characterization 7.2.1 Necessary Conditions
    • حالة الجمود ممكن أن تظهر في حالة تحقق الشروط الأربعة التالية بشكل آني (simultaneously) في النظام :-
    • Mutual exclusion :
    • على الأقل مصدر واحد يجب أن يُحمل في نمط غير قابل للمشاركة (non-sharable mode) ، ذلك ، فقط عملية واحدة في نفس الوقت ممكن أن تستخدم المصدر . و إذا حاولت عملية أخرى طلب هذا المصدر، العملية الطالبة يجب أن تتأخر حتى يصبح المصدر شاغر .
    • 2. Hold and wait :
    • هناك يَجِبُ أَنْ يَجدَ عملية التي تَحْملُ على الأقل مصدرَ واحد و تنتظر الحصول على مصادر إضافية وهذه المصادر حالياً محملة من قبل عملياتِ اخرى .
  • 9. 7.2 Deadlock Characterization 7.2.1 Necessary Conditions
    • 3. No preemption ( حق الشفعة ) :
    • المصادر لا يُمْكن أنْ تُمْنَعَ، ذلك أن المصدر يُمْكِنُ أَنْ يُترك فقط طوعاً من العمليةِ التي تحمله بعد أن تنهي هذه العملية مهمتها .
  • 10. 7.2 Deadlock Characterization 7.2.1 Necessary Conditions
    • 4. Circular wait:
    • هناك يَجِبُ أَنْ تجدَ المجموعة : {P 0 , P 1 , …, P n } من العمليات المنتظرة مثال ذلك :
    • P 0 منتظرة من أجل المصدر المحمل بواسطة P 1 ،
    • P 1 منتظرة من أجل المصدر المحمل بواسطة P 2 ،
    • P 2 منتظرة من أجل المصدر المحمل بواسطة P 3 ، .... ،
    • P n-1 منتظرة من أجل المصدر المحمل بواسطة P n ،
    • P n منتظرة من أجل المصدر المحمل بواسطة P 0 .
  • 11. 7.2 Deadlock Characterization 7.2.1 Necessary Conditions
    • نؤكد مرة أخرى أن الشروط الأربعة لابد أن تكون متحققة كي تحدث مشكلة الجمود (Deadlock problem) .
    • شرط الـ Circular-wait ينتج عنه شرط الـ hold-and-wait ، لذلك الشروط الأربعة ليست مستقلة تماماً .
  • 12. 7.2.2 Resource-Allocation Graph الرسم البياني للمصدر المخصص ( المحجوز )
    • مشكلة الجمود (deadlock) ممكن أن توضح بشكل أفضل عن طريق الرسم البياني الموجه المسى بـ System resource-allocation graph .
    • هذا الرسم البياني يتكون من مجموعة من القمم (vertices) V ومجموعة من الحافات (edges) E .
    • مجموعة القمم V قسمت إلى نوعين مختلفين من العقد (nodes) :
    • المجموعة P = {P 1 , P 2 , …, P n } تتكون من كل العمليات النشطة في النظام .
    • المجموعة R = {R 1 , R 2 , …, R m } تتكون من كل أنواع المصادر في النظام .
  • 13. 7.2.2 Resource-Allocation Graph الرسم البياني للمصدر المخصص ( المحجوز )
    • الحافة (edge) المباشرة من العملية P i إلى نوع المصدر R j يشار إليها بـواسطة : P i ->R j و يعني هذا أن العملية P i طلبت حالة نوع المصدر R j وأن هذه العملية تنتظر من أجل هذا المصدر .
    • الحافة المباشرة من نوع المصدر R j إلى العملية P i يشار إليها بواسطة R i ->P j و يعني هذا أن حالة نوع المصدر R i تم حجزها للعملية P i .
    • الحافة المباشرة : P i ->R j تسمى request edge .
    • الحافة المباشرة : R i ->P j تسمى assignment edge .
  • 14. 7.2.2 Resource-Allocation Graph الرسم البياني للمصدر المخصص ( المحجوز )
    • بشكل تصويري سوف نعرض كل عملية P i على هيئة دائرة و كل نوع مصدر R j على هيئة مربع .
    • حيث أن نوع المصدر R j ربما يملك أكثر من حالة ، سوف نعرض كل حالة على هيئة نقطة (dot) داخل المربع .
    • Note that a request edge points to only the square R j , whereas an assignment edge must also designate one of the dots in the square.
    • المُلاحظة التي أن حافة طلبِ تُشيرُ إلى فقط المربع Rj ، بينما حافة مهمةِ يَجِبُ أيضاً أَنْ تُعيّنَ إحدى النقاطِ في المربعِ .
  • 15. 7.2.2 Resource-Allocation Graph الرسم البياني للمصدر المخصص ( المحجوز )
    • رسم تخصيص المصدر كما بشكل (7.1) يصور الحالة التالية :
    • The sets P, R, and E:
    • - P = {P 1 , P 2 , P 3 }
    • - R = {R 1 , R 2 , R 3 , R 4 }
    • - E = {P 1 ->R 1 , P 2 -> R 3 , R 1 -> P 2 , R 2 -> P 2 , R 2 -> P 1 ,R 3 -> P 3 }
  • 16. 7.2.2 Resource-Allocation Graph الرسم البياني للمصدر المخصص ( المحجوز )
    • تابع رسم تخصيص المصدر كما بشكل (7.1) يصور الحالة التالية :
    • Resource Instances:
    • - One instance of resource type R 1
    • - Two instance of resource type R 2
    • - One instance of resource type R 3
    • - Three instance of resource type R 4
  • 17. الرسم البياني للمصدر المخصص ( المحجوز )
    • تابع رسم تخصيص المصدر كما بشكل (7.1) يصور الحالة التالية :
    • Process States
    • - Process P 1 is holding an instance of resource type R 2 , and is waiting for an instance of resource type R 1 .
    • - Process P 2 is holding an instance of resource type R1and R2, and is waiting for an instance of resource type R 3 .
    • - Process P 3 is holding an instance of resource type R 3
  • 18. Figure 7.1: Resource-allocation graph R 1 R 3 P 1 P 2 P 3 R 2 R 4
  • 19. 7.2.2 Resource-Allocation Graph الرسم البياني للمصدر المخصص ( المحجوز )
    • شكل (7.2) يصور احدى حالات الجمود (deadlock) كما يلي :
    • P 1 ->R 1 -> P 2 ->R 3 ->P 3 ->R 2 ->P 1
    • P 2 ->R 3 ->P 3 ->R 2 ->P 2
    • مهمة للغاية
  • 20. Figure 7.2: Resource-allocation graph with a deadlock R 1 R 3 P 1 P 2 P 3 R 2 R 4
  • 21. Resource-allocation graph with a cycle but no deadlock
    • لاحظ بقوة شديدة جداً :
    • في بعض الأحيان ممكن أن يحدث cycle و لكن بدون حدوث deadlock كما في الشكل (7.3) .
    • من هذا الشكل نجد أن :
    • P1 ->R1, R1->P3, P3 ->R2, R2 ->P1
    • هذا يمثل Cycle و ليس deadlock لأن R1 لها two instance واحد محجوز لـ P3 و الأخر محجوز لـ P4 مع العلم أن P4 ليس لها متطلبات و سوف تنهي عملها بعد مدة محددة من الزمن و تحجز P1 المصدر R2 و بهذا نثبت أنه ليس هناك deadlock .
  • 22. Figure 7.3: Resource-allocation graph with a cycle but no deadlock P 1 P 2 P 3 P 4 R 1 R 2
  • 23. 7.3 Methods for handling Deadlocks
    • عملياً يوجد ثلاثة طرق مختلفة للتعامل مع مشكلة الجمود (Deadlock) هم :
    • ممكن استخدام بروتوكول للتأكد من النظام لن يدخل في حالة جمود (Deadlock state) .
    • ممكن السماح للنظام بادخال حالة الجمود و من ثم عمل استرداد أو تغطيه (recover) لهذا النظام .
    • ممكن تجاهل المشكلة كله مع بعض و نتظاهر بأن الجمود لن يحدث بالنظام .
    • الحل الثالث موجود في معظم نظم التشغيل شاملاً نظام UNIX أيضاً .
  • 24. 7.3 Methods for handling Deadlocks
    • للتأكد من أن حالة الجمود لن تحدث، على النظام أن يستخدم إحدا الأسلوبين :-
    • Deadlock-prevention ( منع الجمود )
    • Deadlock-avoidance ( اجتناب الجمود )
  • 25. 7.3 Methods for handling Deadlocks
    • Deadlock prevention is a set of method for ensuring that at least one of the necessary conditions cannot hold.
    • أي أن الـ Deadlock prevention هو مجموعة من الطرق للتأكد من أن أحد الشروط الضرورية لن تتحقق .
    • Deadlock avoidance , on the other hand, requires that the OS be given in advance additional information concerning which resource a process will request and use during lifetime.
  • 26. 7.4 Deadlock Prevention
    • كما هو معلوم مسبقاً، من أجل حدوث جمود لابد من تحقق أربعة شروط ضرورية .
    • إذاً إذا تم التحقق من أن أحد هذه الشروط لن يتحقق ، معنى ذلك أن حالة الحمود لن تحدث . و بذلك نكون قد منعنا حدوث حالة الجمود .
    • من أجل ذلك سوف نستعرض الشروط الضرورية الأربعة مرة أخرى و تقديم الفكرة التي تمنع تحقق الشرط .
  • 27. 7.4 Deadlock Prevention 7.4.1 Mutual Exclusion
    • الـ Mutual Exclusion يجب أن يتحقق عند المصادر الغير مشاركة (non-sharable resources) .
    • على سبيل المثال :
    • الطابعة لا تستطيع المشاركة في نفس الوقت مع العديد من العمليات .
    • من جهة أخرى المصادر المشاركة لا تحتاج Mutually exclusive access و بهدا لن يحدث جمود (deadlock) .
    • من الأمثلة الجيدة للمصادر المشاركة ملفات القراءة فقط (read-only files)
  • 28. 7.4 Deadlock Prevention 7.4.1 Mutual Exclusion
    • من الأمثلة الجيدة للمصادر المشاركة ملفات القراءة فقط (read-only files) .
    • إذا كان هناك العديد من العمليات تحاول فتح ملف من نوع read-only-file في نفس الوقت ، نستطيع أن نضمن معالجة هذه الملفات بدون مشاكل .
    • العملية لن تحتاج مطلقا إلى الانتظار من المصادر المشاركة .
    • بشكل عام من غير الممكن منع الـ deadlock بواسطة إنكار الـ mutual exclusion condition حيث أنه من الأكيد أن هناك بعض المصادر الغير مشاركة .
  • 29. 7.4 Deadlock Prevention 7.4.2 Hold and Wait
    • للتأكد من أن شرط Hold-and-wait لن يتحقق في النظام، يجب أن نضمن أن أي عملية لا تطلب مصادرإضافية طالما أنها تحتفظ بمصادراً أخرى .
    • بالطبع هناك إثنين من البروتوكلات التي تعالج ذلك :-
  • 30. 7.4 Deadlock Prevention 7.4.2 Hold and Wait
    • الـ Protocol الأول
    • One protocol that can be used requires each process to request and be allocate all its resources before it begins execution.
    • المقصود من هذا الـ protocol أن أي عملية تطلب مصادر لابد أن يتحقق طلبها بحجز كل المصادر المطلوبة قبل بدأ عملية التنفيذ .
  • 31. 7.4 Deadlock Prevention 7.4.2 Hold and Wait
    • الـ Protocol الثانــــــي :
    • This protocol allows a process to request resources only when the process has none .
    • المقصود من هذا الـ protocol أن أي عملية من حقها أن تطلب مصادر إضافية فقط ، إذا كانت هذه العملية لا تحجز مصادر أخرى .
    • العملية ممكن أن تطلب بعص المصادر و تستخدمهم . قبل أن تستطيع أن تطلب مصادر إضافية . إذاً يجب على هذه العملية أن تترك كل المصادر المحتفظة بها قبل ذلك .
  • 32. 7.4 Deadlock Prevention 7.4.2 Hold and Wait
    • الفرق بين البروتوكولين
    • لشرح الفرق بينهما .
    • نفرض المثال التالي :-
    • مطلوب نسخ data من tape drive إلى disk file ، رتب الـ disk file ، ثم اطبع النتيجة بالطابعة .
  • 33. 7.4 Deadlock Prevention 7.4.2 Hold and Wait
    • الفرق بين البروتوكولين
    • باستخدام الـ protocol الأول :-
    • بالطبع العملية سوف تحجز المصادر الثلاثة بالرغم من أنها لن تحتاج الطابعة إلى بعد إنهاء التفيذ و رغم ذلك عملت Hold لها .
  • 34. 7.4 Deadlock Prevention 7.4.2 Hold and Wait
    • باستخدام الـ protocol الثانـــــي :-
    • تسمح للعملية أولا أن تطلب المصدرين tape drive and disk file .
    • و من ثم تنسخ الـ data من الـ tape إلى الـ disk file .
    • بعد ذلك تترك الاثنين (tape and disk file)
    • ثم بعد ذلك يجب على العملية أن تطلب الـ disk file و الطابعة .
    • بعد عملية الطباعة تقوم العملية بترك الاثنين معاً و من ثم تنهي عملها .
  • 35. 7.4 Deadlock Prevention 7.4.2 Hold and Wait
    • There are two main disadvantages of these protocols:
    • First: resource utilization may be low , since many of the resources may be allocated but unused for long time.
    • Second: Starvation is possible . A process that needs several popular resources may have to wait indefinitely, because at least one of the resources that is needs always allocated to some other processes .
  • 36. 7.4 Deadlock Prevention 7.4.3 No Preemption ( حق الشفعة )
    • للتأكد من أن شرط No Preemption لن يتحقق نستخدم أحد البروتوكولين التاليين :
    • البروتوكول الأول :
    • إذا كان هناك عملية محجوز عندها عدة مصادر و هي في حاجة إلى مصدر إضافي و هذا المصدر غير متوفر لها في الوقت الراهن ( بمعني أنها يجب أن تنتظر ) ، إذاً كل المصادر المحجوزه لهذه العملية تصبح مسموح بها بحق الشفعة . هذا يعني ضمنياً أن هذه المصادر حرة .
  • 37. 7.4 Deadlock Prevention 7.4.3 No Preemption ( حق الشفعة )
    • تابع البروتوكول الأول :
    • المصادر المحررة بحق الشفعة تضاف إلى قائمة المصادر و التي من الممكن أن تكون هناك عمليات أخرى في حالة انتظار لأحد هذه المصادر المحررة .
    • العملية التي تم سحب مصادرها بحق الشفعة لن تعاود محاولة التنفيذ إلا في حالة و احدة فقط ألا و هي حصولها على المصدر التي انتظرت بسببة من الأصل .
    • في حالة حصول العملية التي تم سحب مصادرها بحق الشفعة على المصدر المطلوب . مباشرة تقوم باستراد كل مصادرها المسحوبة منها و تبدأ التفيذ فوراً .
  • 38. 7.4 Deadlock Prevention 7.4.3 No Preemption ( حق الشفعة )
    • البروتوكول الثاني :
    • إذا كانت هناك عملية تطلب بعص المصادر،
    • أولاً تبحث هل هي متوفرة بشكل طبيعي . إذا كان كذلك تحجزهم و تبدأ التنفيذ .
    • إذا كانت هذه المصادر غير متوفرة . إذاً تبحث هل هي متوفرة عند بعض العمليات المنتظرة مصادر إضافية أخرى . إذا كان كذلك باستخدام حق الشفعة تسحب هذه المصادر و تبدأ التنفيذ فوراً .
  • 39. 7.4 Deadlock Prevention 7.4.3 No Preemption ( حق الشفعة )
    • البروتوكول الثاني :
    • إذا كانت هذه المصادر غير متوفرة أيضاً . إذا يجب عليها أن تدخل قائمة الانتظار .
    • بالطبع مادامت هي في حالة انتظار كل مصادرها مهددة بالسحب بحق الشفعة .
    • العملية من حقها فقط أن تعاود محاولة التفيذ إذا توفرت المصادر التي من أجلها دخلت في حالة الانتظار .
    • عندها أيضا تحصل مباشرة على كل مصادرها القديمة .
  • 40. 7.4 Deadlock Prevention 7.4.3 No Preemption ( حق الشفعة )
    • البروتوكول الثاني :
    • Note
    • This protocol is often applied to resources whose state can be easily saved and restored later, such as CPU registers and memory space.
    • It cannot generally be applied to such resources as printers and tape drives.
  • 41. 7.4 Deadlock Prevention 7.4.4 Circular Wait
    • توجد طريقة وحيدة للتأكد من أن شرط circular wait لن يتحقق هو فرض الترتيب الكلي لكل أنواع المصادر . و يتطلب من أي عملية أن تطلب مصادرها بترتيب حسابي تصاعدي .
    • بفرض أن R = {R 1 , R 2 , …, R N } مجموعة من أنواع المصادر . سوف نعطي لكل نوع من المصادر قيمة عددية وحيدة و التي سوف تستخدم في المقارنة بين كل مصدريين و لتحديد أيهما يسبق الأخر في ترتيبنا .
    • توصيفا سوف نعرف دالة أحادية التناظر (one-to-one) F:R  N حيث N هي مجموع الأعداد الحقيقية .
  • 42. 7.4 Deadlock Prevention 7.4.4 Circular Wait
    • مثال : إذا كان لدينا مجموعة أنواع المصادر R و التي تشمل وحدات شرائط مغناطيسية (Magnetic Tape Derive) و وحدات أقراص (Disk Drive) و طابعات .
    • إذاً الدالة F ممكن تعريفها كما يلي :-
    • F (Tape drive) = 1,
    • F (Disk drive) = 5,
    • F (Printers) = 12.
  • 43. 7.4 Deadlock Prevention 7.4.4 Circular Wait
    • للتأكد من أن شرط Circular Wait لن يتحقق نستخدم أحد البروتوكولين التاليين :
    • البروتوكول الأول :
    • كل عملية تستطيع أن تطلب المصادر فقط في ترتيب تزايدي للحساب . لذلك ممكن للعملية أن تبدأ بطلب أي رقم من حالات أنواع المصادر، لنقل أن العملية طلبت المصدر R i . بعد ذلك ممكن أن تطلب المصدر R j إذا و إذا فقط F(R j ) > F(R i ) .
    • إذا كان هناك العديد من أنواع المصادر مطلوبة لحالة ما، فإن طلب وحيد فقط من كل هذه الطلبات يجب أن يصدر . (must be issued)
  • 44. 7.4 Deadlock Prevention 7.4.4 Circular Wait
    • على سبيل المثال :
    • مستخدما الدالة السابقة ، إذا كان هناك عملية تريد أن تستحدم الـ tape drive and printer في نفس الوقت يجب عليها أولاً أن تطلب الـ tape drive و من ثم تطلب الـ printer .
  • 45. 7.4 Deadlock Prevention 7.4.4 Circular Wait
    • البروتوكول الثاني :
    • نستطيع طلب أن ، حينما تطلب عملية حالة نوع مصدر Rj ، عليها أن تترك أي مصدر Ri على فرض أن : F(Ri)>=F(Rj) .
    • إذا تم استخدام كلا البروتوكلين فإن شرط الـ Circular-wait لن يتحقق .
    • ممكن أثبات ذلك باستخدام عملية التناقض . أي نفترض أن شرط الـ Circular-wait متحقق ( موجود ).
  • 46. 7.4 Deadlock Prevention 7.4.4 Circular Wait
    • الاثبات
    • لنفترض مجموعة من العمليات في حالة circular-wait و لتكن :
    • {P0, P1, …, Pn},
    • حيث أن :
    • العملية Pi منتظرة المصدر Ri و الذي هو بدوره محجوز للعملية Pi+1 و هكذا لكل العمليات . أي أن العملية Pn منتظرة المصدر Rn و الذي هو بدوره محجوز للعملية P0 .
  • 47. 7.4 Deadlock Prevention 7.4.4 Circular Wait
    • تابع الاثبات
    • إذاً، العملية Pi+1 تحجز المصدر Ri وتطلب المصدر Ri+1 .
    • إذاً يجب أن تكون : F(Ri) < F(Rj) لكل قيم i
    • و لكن هذا الشرط يعني أن :
    • F(R0) < F(R1) < … < F(Rn) < F(R0)
    • من ذلك نستنتج أن F(R0) < F(R0) و هذا مستحيل .
    • إذاً شرط الـ Circular-wait غير متحقق .
    • لاحظ :- عند تعري دالة F هناك أولويات بمعني مثلا الـ tape لابد أن يسبق الـ printer .
  • 48. 7.5 Deadlock Avoidance
    • بالرغم من كل ما تم أخذه من احتياطات ممكن لسبب ما أو خطأ ما يحدث أن الشروط الأربعة تتحقق و يحدث الجمود لذلك سوف نلجأ إلى ما يسمي بـ Deadlock Avoidance .
    • على سبيل المثال لنفترض نظام به وحدة شريط مغناطيسي واحدة و وحدة طابعة واحدة . و بفرض وجود عملية P سوف تطلب أولا وحدة الشريط المغناطيسي ثم بعد ذلك تطلب وحدة الطابعة . في نفس اللحظة هناك عملية أخرى Q سوف تطلب أولا وحدة الطابعة ثم بعد ذلك وحدة الشريط المغناطيسي .
    • بهذه المعرفة للتسلسل الكامل للطلبات (requests) و المتروكات (releases) لكل عملية، ممكن أن نقرر لكل طلب (request) ما إذا كانت العملية يجب أن تنتظر أم لا .
  • 49. 7.5 Deadlock Avoidance
    • أي طلب جديد يستلزم أن النظام يعتبر المصادر المتاحة حالياً، المصادر المحجوزة حالياً لكل عملية ، و المتطلبات (requests) و المتروكات (releases) المستقبلية لكل عملية كي يقرر أي طلب ممكن تحقيقه و أي طلب أخر ممكن تأخير تنفيذه لتجنب الجمود المحتمل مستقبلاً .
    • هناك العديد من الخوارزميات تختلف في كمية و نوع المعلومات المطلوبة .
  • 50. 7.5 Deadlock Avoidance
    • أبسط و أكثر الموديلات إفادةً يتطلب أن كل عملية تعلن عن أكبر عدد من المصادر في كل نوع التي ربما تحتاجة هذه العملية .
    • إذا أعطيت أولوية المعلومات حول أكبر عدد من المصادر في كل نوع التي ربما تحتاجة هذه العملية إذاً من المحتمل تركيب خوارزم يتأكد أن النظام سوف لن يدخل حالة الجمود .
    • هذا الخوارزم يعرف طريق الـ Deadlock-avoidance
    • حوارزم الـ Deadlock-avoidance يختبر الـ Resource-allocation state ديناميكياً للتأكد من أن شرط الـ circular-wait لا يمكن أن يتحقق .
  • 51. 7.5 Deadlock Avoidance
    • تعريف :
    • الـ resource-allocation state يعرف على أنه عدد المصادر المتاحة و عدد المصادر المحجوزة و كذلك أكبر عدد من المصادر المطلوبة .
  • 52. 7.5 Deadlock Avoidance 7.5.1 Safe State
    • A state is safe if the system can allocate resources to each process (up to its maximum) in some order and still avoid a deadlock.
    • بوضوح أكبر
    • A system is in a safe state only if there exists a safe sequence .
    • A sequences of processes <P1, P2, …, Pn> is safe sequence for the current allocation state if, for each Pi, the resources that Pi can still request can be satisfied by the currently available resources plus the resources held by all the Pj, with j < i.
  • 53. 7.5 Deadlock Avoidance 7.5.1 Safe State
    • In this situation, if the resources that process Pi needs are not immediately available, then Pi can wait until all Pj have finished.
    • When they have finished, Pi can obtain all of its needed resources, complete its designated task, return its allocated resources, and terminate.
    • When Pi terminates, Pi+1 can obtain its needed resources, and so on.
    • If no such sequence exist, then the system state is said to be unsafe .
  • 54. 7.5 Deadlock Avoidance 7.5.1 Safe State
    • A safe state is not a deadlock state.
    • Conversely, a deadlock state is an unsafe state.
    • Not all unsafe states are deadlocks, however (figure 7.4).
    Figure (7.4) Safe, Unsafe, and Deadlock state Spaces Unsafe Safe Deadlock
  • 55. 7.5 Deadlock Avoidance 7.5.1 Safe State
    • An unsafe state may lead to a deadlock. As long as the state is safe, the OS can avoid unsafe (and deadlock) states.
    • In an unsafe state, the OS cannot prevent processes from requesting resources such that a deadlock occurs : the behavior of the processes controls unsafe states.
    • لتوضيح ذلك أنظر المثال التالي :
  • 56. 7.5 Deadlock Avoidance 7.5.1 Safe State
    • We consider a system with 12 magnetic tape drives and 3 processes:P0, P1, and P2.
    • Process p0 requires 10 tapes drives,
    • Process p1 may need as many 4, and
    • Process p2 may need up to 9 tape drives.
    • Suppose that, at time t0 ,
    • process P0 is holding 5 tape drives,
    • Process p1 is holding 2, and
    • Process p2 is holding 2 tape drives.
    • (thus, there are 3 free tape drives.)
  • 57. 7.5 Deadlock Avoidance 7.5.1 Safe State
    • At time t0, the system is in a safe state. The sequence <P1, P0, P2> satisfies the safety condition , since process P1 can immediately be allocated all its tape drives and then return them (the system will then have 5 available tape drives)
    Max. Needs Current Needs P0 10 5 P1 4 2 P2 9 2
  • 58. 7.5 Deadlock Avoidance 7.5.1 Safe State
    • Then process P0 can get all its tape drives and return them (the system will then have 10 available tape drives), and finally process P2 could get all its tape drives an return them (the system will then have all 12 available tape drives).
    • ممكن أيضا ً الانتقال من حالة الـ Safe إلى حالة الـ Unsafe .
    • Suppose that, at time t1, process P2 requests and allocated 1 more tape drive. The system is no longer in a safe state .
  • 59. 7.5 Deadlock Avoidance 7.5.1 Safe State
    • At this point , only process P1can be allocated all its tape drives. When it return them, the system will have only 4 available tape drive. Since process P0 is allocated 5 tape drives, but has a maximum of 10, it may then request 5 more tape drives. Since they are unavailable, process P0 must wait. Similarly, process P2 may request an additional 6 tape drives and have to wait, resulting in a deadlock.
  • 60. 7.5 Deadlock Avoidance 7.5.1 Safe State
    • Given the concept of a safe state, we can define avoidance algorithms that ensure that the system will never deadlock. The idea is simply to ensure that the system will always remain in a safe state. Initially, the system is in a safe state.
    • Whenever a process requests a resource that is currently available, the system must decide whether the resource can be allocated immediately or whether the process must wait. The request is granted only if the allocation leaves the system in a safe state.
  • 61. تمت بحمد الله تعالى و فضله