مقدمة لأنظمة التشغيل
يا هبر! أود أن ألفت انتباهكم إلى سلسلة من المقالات - ترجمات لأدب مثير للاهتمام في رأيي - OSTEP. تناقش هذه المادة بعمق عمل أنظمة التشغيل الشبيهة بـ unix ، أي العمل مع العمليات ، وبرامج الجدولة المختلفة ، والذاكرة ، والمكونات الأخرى المماثلة التي تشكل نظام تشغيل حديث. يمكنك مشاهدة النسخة الأصلية لجميع المواد هنا . يرجى ملاحظة أن الترجمة تمت بطريقة غير احترافية (بحرية تامة) ، لكنني آمل أن أحتفظ بالمعنى العام.
يمكن العثور على عمل معمل حول هذا الموضوع هنا:
أجزاء أخرى:
يمكنك أيضًا التحقق من قناتي على =)
التخطيط: قائمة انتظار الملاحظات متعددة المستويات
سنتحدث في هذه المحاضرة عن مشاكل تطوير أحد أشهر الأساليب
التخطيط، وهو ما يسمى قائمة انتظار الملاحظات متعددة المستويات (MLFQ). تم وصف برنامج جدولة MLFQ لأول مرة في عام 1962 بواسطة فرناندو جي كورباتو في نظام يسمى
نظام مشاركة الوقت المتوافق (CTSS). هذه الأعمال (بما في ذلك الأعمال اللاحقة على
Multics) تم ترشيحهم لاحقًا لجائزة تورينج. كان المجدول
تم تحسينه لاحقًا واكتسب المظهر الذي يمكن العثور عليه بالفعل
بعض الأنظمة الحديثة .
تحاول خوارزمية MLFQ حل مشكلتين أساسيتين متداخلتين.
أولا، فهو يحاول تحسين وقت الاستجابة، والذي، كما ناقشنا في المحاضرة السابقة، تم تحسينه من خلال طريقة التشغيل على رأس قائمة الانتظار أكثر
مهام قصيرة. ومع ذلك، فإن نظام التشغيل لا يعرف كم من الوقت سيتم تشغيل هذه العملية أو تلك، وهذا
المعرفة اللازمة لتشغيل خوارزميات SJF وSTCF. ثانيا، يحاول MLFQ
جعل النظام مستجيبًا للمستخدمين (على سبيل المثال، لأولئك الذين يجلسون و
التحديق في الشاشة أثناء انتظار اكتمال المهمة) وبالتالي تقليل الوقت
إجابة. لسوء الحظ، فإن الخوارزميات مثل RR تقلل من وقت الاستجابة، ولكن
لها تأثير سيء على مقياس وقت الاستجابة. ومن هنا مشكلتنا: كيفية التصميم
المجدول الذي سيلبي متطلباتنا وفي نفس الوقت لا يعرف شيئًا عنه
طبيعة العملية بشكل عام؟ كيف يمكن للمجدول أن يتعلم خصائص المهام،
الذي يطلقه وبالتالي اتخاذ قرارات جدولة أفضل؟
جوهر المشكلة: كيف تخطط لتحديد المهام دون معرفة كاملة؟
كيفية تصميم برنامج جدولة يقلل وقت الاستجابة في نفس الوقت
للمهام التفاعلية وفي نفس الوقت يقلل من وقت الاستجابة دون معرفة ذلك
معرفة وقت تنفيذ المهمة؟
ملاحظة: التعلم من الأحداث السابقة
تعد قائمة انتظار MLFQ مثالاً ممتازًا للنظام الذي تم التدريب عليه
الأحداث الماضية للتنبؤ بالمستقبل. مثل هذه الأساليب غالبا ما تكون
موجودة في نظام التشغيل (والعديد من الفروع الأخرى في علوم الحاسوب، بما في ذلك فروع
تنبؤات الأجهزة وخوارزميات التخزين المؤقت). ارتفاعات مماثلة
يتم تشغيله عندما يكون للمهام مراحل سلوكية وبالتالي يمكن التنبؤ بها.
ومع ذلك، ينبغي للمرء أن يكون حذرا مع هذه التقنية، لأن التنبؤات سهلة للغاية.
قد يتبين أن الأمر خاطئ ويقود النظام إلى اتخاذ قرارات أسوأ من ذلك
سيكون بدون علم على الإطلاق.
MLFQ: القواعد الأساسية
خذ بعين الاعتبار القواعد الأساسية لخوارزمية MLFQ. وعلى الرغم من أن تطبيقات هذه الخوارزمية
هناك العديد، والنهج الأساسية متشابهة.
في التنفيذ الذي سننظر فيه، سيكون لدى MLFQ العديد
طوابير منفصلة، ولكل منها أولوية مختلفة. في أي وقت،
المهمة الجاهزة للتنفيذ موجودة في نفس قائمة الانتظار. يستخدم MLFQ الأولويات،
لتحديد المهمة التي سيتم تشغيلها للتنفيذ، أي. المهمة مع أعلى
سيتم إطلاق الأولوية (مهمة من قائمة الانتظار ذات الأولوية القصوى) في البداية
طابور.
وبطبيعة الحال، يمكن أن يكون هناك أكثر من مهمة واحدة في قائمة انتظار معينة، لذلك
لذلك سيكون لديهم نفس الأولوية. في هذه الحالة، سيتم استخدام الآلية
RR لتخطيط الإطلاق بين هذه المهام.
وهكذا نصل إلى قاعدتين أساسيتين لـ MLFQ:
- القاعدة 1: إذا كانت الأولوية (أ) > الأولوية (ب)، فسيتم تشغيل المهمة أ (لن يتم تشغيل المهمة ب)
- القاعدة 2: إذا كانت الأولوية (A) = الأولوية (B)، فسيتم بدء A&B باستخدام RR
بناءً على ما سبق، فإن العناصر الأساسية لتخطيط MLFQ هي:
هي الأولويات. بدلاً من إعطاء أولوية ثابتة لكل منها
المهمة، يغير MLFQ أولويته اعتمادًا على السلوك الذي تمت ملاحظته.
على سبيل المثال، إذا تم إنهاء مهمة باستمرار على وحدة المعالجة المركزية أثناء انتظار إدخال لوحة المفاتيح،
سيحافظ MLFQ على أولوية العملية العالية لأن هذه هي الطريقة
يجب أن تعمل العملية التفاعلية. على العكس من ذلك، إذا كانت المهمة مستمرة و
إذا كانت وحدة المعالجة المركزية مكثفة لفترة طويلة، فسوف تقوم MLFQ بتخفيضها
أولوية. وبالتالي، سوف يقوم MLFQ بدراسة سلوك العمليات في وقت تشغيلها.
واستخدام السلوكيات.
لنرسم مثالاً على الشكل الذي قد تبدو عليه قوائم الانتظار في مرحلة ما
الوقت ثم تحصل على شيء مثل هذا:
في هذا المخطط، توجد عمليتان A وB في قائمة الانتظار ذات الأولوية العليا. عملية
يقع C في مكان ما في المنتصف، وتكون العملية D في نهاية قائمة الانتظار. وفقا لما سبق
أوصاف خوارزمية MLFQ، سيقوم المجدول فقط بتنفيذ المهام ذات أعلى المستويات
الأولوية وفقًا لـ RR، وستكون المهام C وD خارج العمل.
وبطبيعة الحال، لن تعطي اللقطة الثابتة صورة كاملة عن كيفية عمل MLFQ.
من المهم أن نفهم بالضبط كيف تتغير الصورة بمرور الوقت.
المحاولة 1: كيفية تغيير الأولوية
في هذه المرحلة، عليك أن تقرر كيف سيغير MLFQ مستوى الأولوية
المهمة (وبالتالي موضع المهمة في قائمة الانتظار) خلال دورة حياتها. ل
لهذا، عليك أن تضع في اعتبارك سير العمل: مبلغ معين
مهام تفاعلية ذات أوقات تشغيل قصيرة (وبالتالي إصدار متكرر
وحدة المعالجة المركزية) والعديد من المهام الطويلة التي تستخدم وحدة المعالجة المركزية طوال وقت عملها
زمن الاستجابة لمثل هذه المهام ليس مهما. وهكذا يمكنك القيام بالمحاولة الأولى
قم بتنفيذ خوارزمية MLFQ بالقواعد التالية:
- القاعدة 3: عندما تدخل مهمة إلى النظام، يتم وضعها في قائمة الانتظار ذات الأعلى
- الأولوية.
- القاعدة 4 أ: إذا كانت المهمة تستخدم نافذتها الزمنية بالكامل، فستكون كذلك
- تم تخفيض الأولوية.
- القاعدة 4 ب: إذا قامت مهمة ما بتحرير وحدة المعالجة المركزية قبل انتهاء صلاحية النافذة الزمنية الخاصة بها، فهذا يعني أنها
- يبقى بنفس الأولوية.
مثال 1: مهمة واحدة طويلة الأمد
كما ترون في هذا المثال، تم تعيين المهمة عند القبول على المستوى الأعلى
أولوية. بعد فترة زمنية قدرها 10 مللي ثانية، يتم خفض أولوية العملية.
جدولة. بعد نافذة المرة التالية، يتم أخيرًا خفض مستوى المهمة إلى
الأولوية الدنيا في النظام، حيث يبقى.
مثال 2: التقطت مهمة قصيرة
الآن دعونا نرى مثالاً لكيفية محاولة MLFQ التعامل مع SJF. في هذا
على سبيل المثال، مهمتان: أ، وهي مهمة طويلة الأمد باستمرار
احتلال وحدة المعالجة المركزية وB، وهي مهمة تفاعلية قصيرة. يفترض
أن A كان قيد التشغيل لبعض الوقت بحلول وقت وصول المهمة B.
ويوضح هذا الرسم البياني نتائج السيناريو. المهمة أ مثل أي مهمة
كان استخدام وحدة المعالجة المركزية في الأسفل. ستصل المهمة B في الوقت T=100 وستصل
وضعت في قائمة الانتظار ذات الأولوية القصوى. وبما أن وقت التشغيل قصير،
سوف يكتمل قبل أن يصل إلى قائمة الانتظار الأخيرة.
من هذا المثال، يجب أن تفهم الهدف الرئيسي للخوارزمية: حيث أن الخوارزمية لا تفعل ذلك
إذا عرف مهمة طويلة أو قصيرة، فإنه يتولى هذه المهمة أولاً
قصيرة ويعطيها الأولوية القصوى. إذا كانت حقًا مهمة قصيرة، إذن
سيتم تنفيذها بسرعة، وإلا إذا كانت مهمة طويلة فسوف تتحرك ببطء
في الأولوية لأسفل وسوف تثبت قريبا أنها في الواقع مهمة طويلة لا
يتطلب الرد.
مثال 3: ماذا عن الإدخال/الإخراج؟
الآن دعونا نلقي نظرة على مثال الإدخال/الإخراج. كما هو مذكور في القاعدة 4 ب،
إذا قامت إحدى العمليات بتحرير المعالج دون استخدام وقت المعالج بالكامل،
ثم يبقى على نفس مستوى الأولوية. القصد من هذه القاعدة بسيط جدا.
- إذا كانت المهمة التفاعلية تنفذ الكثير من عمليات الإدخال/الإخراج، على سبيل المثال، في انتظار
من ضغطات المفاتيح أو الماوس للمستخدم، فإن مثل هذه المهمة ستحرر المعالج
قبل النافذة المخصصة. ولا نريد أن نغفل مثل هذه المهمة ذات الأولوية،
وبالتالي سيبقى على نفس المستوى.
يوضح هذا المثال كيفية عمل الخوارزمية مع مثل هذه العمليات - المهمة التفاعلية B، والتي تحتاج فقط إلى وحدة المعالجة المركزية لمدة 1 مللي ثانية قبل التنفيذ
عملية الإدخال/الإخراج والمهمة الطويلة أ، والتي تستخدم وحدة المعالجة المركزية طوال الوقت.
يحافظ MLFQ على العملية B في الأولوية القصوى مع استمرارها في ذلك
الافراج عن وحدة المعالجة المركزية. إذا كانت B مهمة تفاعلية، فقد وصلت الخوارزمية في هذه الحالة
والغرض منه هو إطلاق المهام التفاعلية بسرعة.
مشاكل في خوارزمية MLFQ الحالية
في الأمثلة السابقة، قمنا ببناء إصدار أساسي من MLFQ. ويبدو أنه
يقوم بعمله بشكل جيد وعادل، ويوزع وقت وحدة المعالجة المركزية بشكل عادل بين
المهام الطويلة والسماح بالمهام القصيرة أو المهام التي يتم الوصول إليها بكثافة
إلى الإدخال/الإخراج للمعالجة بسرعة. ولسوء الحظ، فإن هذا النهج يحتوي على عدة
مشاكل خطيرة.
أولا, مشكلة الجوع: إذا كان النظام سيحتوي على العديد من التفاعلات
المهام، فإنها سوف تستهلك كل وقت وحدة المعالجة المركزية، وبالتالي لن تكون طويلة
المهمة لن تحظى بفرصة التنفيذ (إنهم يتضورون جوعا).
ثانيايمكن للمستخدمين الأذكياء كتابة برامجهم بهذه الطريقة
خداع المجدول. الخداع يكمن في القيام بشيء من أجل القوة
جدولة لإعطاء العملية المزيد من الوقت لوحدة المعالجة المركزية. الخوارزمية التي
الموصوفة أعلاه معرضة تمامًا لمثل هذه الهجمات: قبل أن تكون النافذة الزمنية عمليا
بعد ذلك، تحتاج إلى إجراء عملية الإدخال / الإخراج (للبعض، بغض النظر عن الملف)
وبالتالي تحرير وحدة المعالجة المركزية. سيسمح لك هذا السلوك بالبقاء كما هو
قائمة الانتظار نفسها وتحصل مرة أخرى على نسبة أكبر من وقت وحدة المعالجة المركزية. إذا تم ذلك
هذا صحيح (على سبيل المثال، تشغيل 99% من وقت النافذة قبل تحرير وحدة المعالجة المركزية)،
مثل هذه المهمة يمكن أن تحتكر المعالج ببساطة.
وأخيرا، يمكن للبرنامج أن يغير سلوكه مع مرور الوقت. تلك المهام
التي تستخدم وحدة المعالجة المركزية يمكن أن تصبح تفاعلية. في مثالنا مماثل
لن تتلقى المهام العلاج المناسب من المجدول، كما يفعل الآخرون
(الأصل) المهام التفاعلية.
سؤال للجمهور: ما هي الهجمات التي يمكن شنها على المجدول في العالم الحديث؟
المحاولة 2: زيادة الأولوية
دعونا نحاول تغيير القواعد ومعرفة ما إذا كان بإمكاننا تجنب المشاكل
مجاعة. ماذا يمكننا أن نفعل للتأكد من أن ذات الصلة
سوف تحصل مهام وحدة المعالجة المركزية على وقتها (حتى لو لم يكن طويلاً).
كحل بسيط للمشكلة، يمكنك أن تقترح بشكل دوري
زيادة أولوية جميع هذه المهام في النظام. هناك عدة طرق
ولتحقيق ذلك، دعونا نحاول تنفيذ شيء بسيط كمثال: الترجمة
جميع المهام في وقت واحد إلى الأولوية القصوى، ومن هنا جاءت القاعدة الجديدة:
- Rule5: بعد مرور بعض الوقت، قم بنقل جميع المهام في النظام إلى أعلى قائمة انتظار.
قاعدتنا الجديدة تحل مشكلتين في وقت واحد. أولا، العمليات
ضمان عدم المجاعة: سيتم مشاركة المهام الموجودة في قائمة الانتظار الأعلى
وقت المعالج وفقًا لخوارزمية RR وبالتالي ستتلقى جميع العمليات
وقت المعالج. ثانيا، إذا كانت بعض العمليات التي استخدمت سابقا
يصبح المعالج فقط تفاعليًا، وسيبقى في قائمة الانتظار مع الأعلى
الأولوية بعد تلقي دفعة إلى الأولوية العليا مرة واحدة.
النظر في مثال. في هذا السيناريو، فكر في عملية واحدة باستخدام
وحدة المعالجة المركزية واثنين من العمليات التفاعلية القصيرة. على يسار الشكل، يوضح الشكل السلوك دون تعزيز الأولوية، وبالتالي تبدأ المهمة طويلة المدى في التباطؤ بعد وصول مهمتين تفاعليتين إلى النظام. في الشكل الموجود على اليمين، يتم إجراء زيادة في الأولوية كل 50 مللي ثانية وبالتالي يتم ضمان حصول جميع العمليات على وقت المعالج وسيتم بدء تشغيلها بشكل دوري. يتم أخذ 50 مللي ثانية في هذه الحالة كمثال، ولكن في الواقع هذا الرقم أعلى إلى حد ما.
ومن الواضح أن إضافة زمن الصعود الدوري S يؤدي إلى
سؤال منطقي: ما هي القيمة التي ينبغي تحديدها؟ واحدة من المستحقين
أشار مهندسو الأنظمة جون أوسترهوت إلى كميات مماثلة في الأنظمة باسم voo-doo
ثابت، لأنهم بطريقة ما يحتاجون إلى السحر الأسود من أجل التصحيح
التعرض. ولسوء الحظ، S لديه مثل هذه النكهة. إذا قمت بتعيين القيمة أيضا
كبيرة - المهام الطويلة سوف تتضور جوعا. وإذا قمت بتعيينه منخفضة للغاية،
لن تتلقى المهام التفاعلية وقتًا مناسبًا لوحدة المعالجة المركزية.
المحاولة 3: محاسبة أفضل
الآن لدينا مشكلة أخرى يجب حلها: كيف لا نفعل ذلك
السماح للغش جدولة لدينا؟ الجناة لهذا الاحتمال هم
القواعد 4 أ، 4 ب التي تسمح للمهمة بالحفاظ على أولويتها عن طريق تحرير المعالج
قبل انتهاء الوقت المخصص . كيفية التعامل معها؟
يمكن اعتبار الحل في هذه الحالة حسابًا أفضل لوقت وحدة المعالجة المركزية في كل منها
مستوى MLFQ. بدلا من أن ننسى الوقت الذي استخدمه البرنامج
المعالج للفاصل الزمني المخصص، يجب أن تأخذ بعين الاعتبار وحفظه. بعد
لقد استنفدت العملية الوقت المخصص لها، وينبغي تخفيض رتبتها إلى المرحلة التالية
مستوى الأولوية. الآن لا يهم كيف ستستخدم العملية وقتها - كيف
الحوسبة باستمرار على المعالج أو على شكل مجموعة من المكالمات. هكذا،
يجب إعادة كتابة القاعدة 4 على النحو التالي:
- Rule4: بعد أن تستهلك المهمة الوقت المخصص لها في قائمة الانتظار الحالية (بغض النظر عن عدد المرات التي حررت فيها وحدة المعالجة المركزية)، يتم تقليل أولوية هذه المهمة (تنتقل إلى أسفل قائمة الانتظار).
لنلقي نظرة على مثال:
»
يوضح الشكل ما يحدث إذا حاولت خداع المجدول
إذا كان الأمر مع القواعد السابقة 4أ، فإن 4ب ستكون النتيجة على اليسار. مع الجديد
القاعدة هي أن النتيجة على اليمين. قبل الحماية، يمكن لأي عملية استدعاء الإدخال/الإخراج قبل اكتمالها
وبالتالي تهيمن على وحدة المعالجة المركزية، بعد تمكين الحماية، بغض النظر عن السلوك
I/O، سيظل في قائمة الانتظار، وبالتالي لن يتمكن من القيام بذلك بطريقة غير شريفة
الاستيلاء على موارد وحدة المعالجة المركزية.
تحسين MLFQ وغيرها من القضايا
مع التحسينات المذكورة أعلاه، تنشأ مشاكل جديدة: واحدة من أهمها
الأسئلة - كيفية تحديد مثل هذا المجدول؟ أولئك. كم ينبغي أن يكون
طوابير؟ ما هو حجم نافذة البرنامج ضمن قائمة الانتظار؟ كيف
ينبغي في كثير من الأحيان إعطاء الأولوية للبرنامج لتجنب المجاعة و
لتأخذ في الاعتبار التغيير في سلوك البرنامج؟ لهذه الأسئلة، ليس هناك بسيطة
الاستجابة والتجارب فقط مع الأحمال والتكوين اللاحق
جدولة يمكن أن يؤدي إلى بعض التوازن المرضي.
على سبيل المثال، تسمح لك معظم تطبيقات MLFQ بتعيين مختلف
فترات زمنية لقوائم الانتظار المختلفة. عادة ما تكون قوائم الانتظار ذات الأولوية العالية
فترات قصيرة. تتكون قوائم الانتظار هذه من مهام تفاعلية،
يعد التبديل بينهما حساسًا جدًا ويجب أن يستغرق 10 أو أقل
آنسة. في المقابل، تتكون قوائم الانتظار ذات الأولوية المنخفضة من مهام طويلة الأمد تستخدم
وحدة المعالجة المركزية. وفي هذه الحالة، تتناسب الفواصل الزمنية الطويلة بشكل جيد جدًا (100 مللي ثانية).
في هذا المثال، هناك مهمتان عملتا في قائمة الانتظار ذات الأولوية العالية 2
مللي مقسمة إلى نوافذ 10 مللي ثانية. 40 مللي ثانية في قائمة الانتظار الوسطى (نافذة 20 مللي ثانية) وفي قائمة الانتظار ذات الأولوية المنخفضة
أصبحت نافذة وقت الانتظار 40 مللي ثانية حيث أكملت المهام عملها.
يعد تطبيق MLFQ في نظام التشغيل Solaris فئة من برامج جدولة مشاركة الوقت.
سيوفر المجدول مجموعة من الجداول التي تحدد بالضبط كيف ينبغي ذلك
تغيير أولوية العملية على مدى حياتها، ما ينبغي أن يكون الحجم
النافذة التي سيتم تخصيصها وعدد مرات رفع أولويات المهام. مدير
يمكن للنظام التفاعل مع هذا الجدول وجعل المجدول يتصرف
بشكل مختلف. بشكل افتراضي، يحتوي هذا الجدول على 60 قائمة انتظار مع زيادة تدريجية
حجم النافذة من 20 مللي ثانية (أولوية عالية) إلى عدة مئات مللي ثانية (أولوية أدنى)، و
أيضًا مع تعزيز جميع المهام مرة واحدة في الثانية.
لا تستخدم برامج جدولة MLFQ الأخرى جدولاً أو أي جدول محدد
القواعد الموضحة في هذا الفصل، على العكس من ذلك، تحسب الأولويات باستخدام
الصيغ الرياضية. على سبيل المثال، يستخدم المجدول في FreeBSD صيغة لـ
حساب أولوية المهمة الحالية بناءً على مقدار العملية
تستخدم وحدة المعالجة المركزية. بالإضافة إلى ذلك، فإن استخدام وحدة المعالجة المركزية يتعفن بمرور الوقت، وبالتالي
ومن ثم، فإن زيادة الأولوية تختلف بعض الشيء عما هو موضح أعلاه. هذا صحيح
تسمى خوارزميات الاضمحلال. اعتبارًا من الإصدار 7.1، يستخدم FreeBSD برنامج جدولة ULE.
وأخيرا، العديد من المخططين لديهم ميزات أخرى. على سبيل المثال، بعض
يحتفظ المجدولون بمستويات أعلى لتشغيل نظام التشغيل وبالتالي
وبالتالي، لا يمكن لأي عملية مستخدم الحصول على الأولوية القصوى
نظام. تسمح لك بعض الأنظمة بتقديم النصائح للمساعدة
المجدول لتحديد الأولويات بشكل صحيح. على سبيل المثال، باستخدام الأمر رحلة جميلة
يمكنك زيادة أو تقليل أولوية المهمة وبالتالي زيادة أو تقليلها
تقليل فرص البرنامج لوقت وحدة المعالجة المركزية.
MLFQ: ملخص
لقد وصفنا نهج التخطيط المسمى MLFQ. أسمه
خلص إلى مبدأ التشغيل - فهو يحتوي على عدة قوائم انتظار ويستخدم التعليقات
لتحديد أولويات المهمة.
وسيكون الشكل النهائي للقواعد على النحو التالي:
- Rule1: إذا كانت الأولوية (أ) > الأولوية (ب)، فسيتم تشغيل المهمة أ (لن يتم تشغيل المهمة ب)
- Rule2: إذا كانت الأولوية (A) = الأولوية (B)، فسيتم بدء A&B باستخدام RR
- Rule3: عندما تدخل مهمة إلى النظام، يتم وضعها في قائمة الانتظار ذات الأولوية الأعلى.
- Rule4: بعد أن تستهلك المهمة الوقت المخصص لها في قائمة الانتظار الحالية (بغض النظر عن عدد المرات التي حررت فيها وحدة المعالجة المركزية)، يتم تقليل أولوية هذه المهمة (تنتقل إلى أسفل قائمة الانتظار).
- Rule5: بعد مرور بعض الوقت، قم بنقل جميع المهام في النظام إلى أعلى قائمة انتظار.
يعد MLFQ مثيرًا للاهتمام للسبب التالي - بدلاً من طلب المعرفة
طبيعة المهمة مقدمًا، تتعلم الخوارزمية السلوك السابق للمهمة وتحددها
الأولويات وفقا لذلك. وبالتالي، يحاول الجلوس على كرسيين في وقت واحد - لتحقيق الأداء للمهام الصغيرة (SJF، STCF) وتشغيل المهام الطويلة بصدق،
وظائف تحميل وحدة المعالجة المركزية. ولذلك فإن العديد من الأنظمة، بما في ذلك BSD ومشتقاتها،
يستخدم Solaris وWindows وMac شكلاً من أشكال الخوارزمية كمجدول
MLFQ كخط أساس.
مواد إضافية:
- (الحوسبة)
المصدر: www.habr.com