كيف تحل واجبات عال 227 (CSC 227) - دليل عملي للهوم ورك والمشروع

أول واجب في عال 227 غالبا ما يخوفك من أول نظرة. ورقة عادية، جدول صغير، وخوارزمية اسمها مر عليك في المحاضرة. تقول لنفسك: سهلة.

بعد عشر دقائق تكتشف أنها مو سهلة. مو لأن السؤال عميق جدا، لكن لأنك ضيعت تفصيلة واحدة: عملية وصلت في وقت 3 وليس 0، أو thread كتب على نفس المتغير، أو wait انحطت قبل السطر الغلط. فجأة الحل كله صار يمشي في اتجاه ثاني.

هنا بالضبط تبدأ مادة CSC 227 نظم التشغيل في جامعة الملك سعود. ليست مادة حفظ تعريفات. وليست مادة كود فقط. هي مادة تعلمك تفكر مثل نظام التشغيل: من يأخذ المعالج الآن؟ من ينتظر؟ من يملك المورد؟ ماذا يحدث لو عمليتان طلبتا نفس الشيء في نفس اللحظة؟

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

الحل في المنتصف. تفهم الفكرة، ترسمها بيدك، وبعدها فقط تحولها لكود أو جدول.

هنا نركز على الواجبات نفسها. كيف تبدأ؟ متى ترسم؟ متى تفتح التيرمنال؟ ومتى توقف لأنك تمشي في طريق غلط؟

لن أعطيك كلاما عاما عن “أهمية نظم التشغيل”. أنت غالبا تعرف أنها مهمة. خلنا ندخل في الشيء الذي يضيع الدرجات فعلا.

قبل أي واجب: افهم نوع السؤال

في عال 227، صياغة السؤال أحيانا تخدعك. “طبق Round Robin” تبدو واضحة. “اكتب برنامجا ينشئ عمليات” تبدو مباشرة. “حدد هل الحالة آمنة” تبدو مثل سؤال جداول عادي.

بس كل واحد من هذه الأسئلة يحتاج طريقة بداية مختلفة. الطالب المستعجل يبدأ من النص الأخير في السؤال، ثم يرجع بعد ربع ساعة لأنه نسي يحدد نوع المسألة من الأساس.

قبل الحل، صنف السؤال في دقيقة واحدة:

نوع السؤال	ماذا تفعل أولا؟	الأداة المناسبة
جدولة معالج	ارسم خط الزمن	ورقة وقلم
عمليات في C	حدد الأب والابن	كود صغير وتجربة
Threads	حدد المتغير المشترك	رسم ثم كود
Semaphores	اكتب مناطق الدخول والخروج	pseudocode
Banker	احسب Need	جدول
Paging	افصل page و offset	حساب يدوي

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

واجبات العمليات: fork ليس مجرد سطر كود

أول صدمة عملية في نظم التشغيل غالبا تكون مع fork(). سطر واحد فقط، لكنه يقلب البرنامج. قبل fork() عندك مسار واحد. بعده عندك أب وابن، وكل واحد يكمل من نفس المكان تقريبا.

وهنا يبدأ اللخبطة. عينك تشوف كودا واحدا، لكن النظام يشغل نسختين.

مثال صغير:

#include <stdio.h>
#include <unistd.h>

int main() {
    int x = 5;
    fork();
    x++;
    printf("%d\n", x);
    return 0;
}

كثير من الطلاب يتوقعون أن الناتج يكون 6 مرة واحدة. لكن البرنامج يطبع 6 مرتين، لأن بعد fork() صار عندك عمليتان، وكل عملية عندها نسختها الخاصة من المتغير x.

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

• قبل fork: عملية واحدة
• بعد أول fork: عمليتان
• بعد ثاني fork: غالبا أربع عمليات
• كل عملية تكمل من نفس السطر التالي

والخطأ الثاني يتكرر كثير في الواجبات: نسيان wait(). تكتب الكود، يشتغل، ثم تطلع الطباعة بترتيب غريب. أو يخلص الأب قبل الابن وتبدأ تسأل: ليش الناتج كذا؟

المدرس هنا لا يبحث عن fork() فقط. يبحث هل أنت فاهم العلاقة بين parent و child. هذا الفرق بين كود منسوخ وكود صاحبه يعرف ماذا يحدث داخله.

واجبات الخيوط: المشكلة ليست pthread_create

الخيوط (Threads) تبدو أهدأ من العمليات. لا توجد شجرة، ولا أب وابن، ولا wait() بنفس الشكل. فتقول: ممتاز، هذا أسهل.

غالبا لا.

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

تخيل عندك counter مشترك:

#include <pthread.h>

int counter = 0;

void* add(void* arg) {
    for (int i = 0; i < 1000; i++) {
        counter++;
    }
    return NULL;
}

لو شغلت هذا الكود بخيطين، تتوقع الناتج 2000. أحيانا يطلع أقل. لماذا؟ لأن counter++ ليست خطوة واحدة. هي قراءة، ثم زيادة، ثم كتابة. لو خيطان دخلا في نفس اللحظة، واحد منهم يكتب فوق نتيجة الثاني.

هذا اسمه Race Condition. ولا ينحل بجملة “أستخدم mutex” في التقرير. لازم تعرف أين تضع القفل، والأهم أين لا تضعه.

pthread_mutex_lock(&lock);
counter++;
pthread_mutex_unlock(&lock);

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

كثير من الطلاب يعلقون هنا لأن الكود قد يعمل مرة ويفشل مرة. وهذا أسوأ نوع خطأ، لأنه يعطيك أمل كاذب. مرة يطلع 2000، مرة 1843، مرة 1991. ليس عشوائيا بالمعنى السحري. فقط ترتيب التنفيذ تغير.

خريطة الـ16 أسبوع: أين تتراكم المادة؟

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

الأسابيع	المحتوى	المحطة
1-2	بنية نظام التشغيل وبيئة Linux وSystem Calls	🟢 Setup
3-4	العمليات، PCB، وContext Switching	⚠️ مفهوم العملية
5-6	الخيوط وpthread والمتغيرات المشتركة	🟢 Threads
7-8	جدولة المعالج: FCFS، SJF، SRTF، RR، Priority	⚠️ Scheduling
9-10	التزامن: Mutex، Semaphores، Producer-Consumer	⚠️ Synchronization
11-12	الجمود وخوارزمية Banker	🟡 Deadlock
13-14	الذاكرة: Paging، Page Tables، Page Replacement	⚠️ Memory
15-16	أنظمة الملفات ومراجعة نهائية	🟢 File Systems

لو عندك وقت محدود، لا توزعه بالتساوي. الأسابيع 7-10 مثلا تستحق وقتا أكثر من قراءة عامة، لأنها تجمع الرسم اليدوي والكود والمنطق. أما الأسبوع الأول فهدفه بسيط: جهز البيئة ولا تدخل أول واجب وأنت ما زلت تبحث عن طريقة تشغيل gcc.

CPU Scheduling: لا تثق في إحساسك

أسئلة الجدولة تخدع حتى الطالب الشاطر. تحس أنك فاهم FCFS و SJF و Round Robin، ثم يجي جدول صغير في الكويز ويطلع منك رقم بعيد تماما عن الحل.

السبب بسيط: الجدولة ليست تعريفات. الجدولة تتبع زمن. عملية وصلت الآن. الثانية لها burst أقل. quantum انتهى. عملية رجعت آخر الطابور. كل حركة صغيرة تغير الرسم.

ابدأ دائما بجدول:

Process	Arrival	Burst
P1	0	7
P2	2	4
P3	4	1
P4	5	4

لو الخوارزمية FCFS، الحل يمشي حسب الوصول. لو SJF غير قابل للمقاطعة، تنتظر العملية الحالية حتى تنتهي ثم تختار الأقصر من الموجود. لو SRTF، أي عملية جديدة قد تقاطع الحالية. لو Round Robin، كل عملية تأخذ quantum ثم ترجع آخر الطابور إذا لم تنته.

لا تحسب waiting time من البداية. هذه عادة سيئة. ارسم Gantt chart أولا، واترك الحسابات للنهاية. بعد الرسم، احسب:

• Completion time
• Turnaround time = Completion - Arrival
• Waiting time = Turnaround - Burst

هذه الطريقة أبطأ في أول أسبوع، نعم. لكنها أسرع في الاختبار، لأنها تمنعك من التصحيح العكسي. الطالب الذي يحسب كل شيء أثناء الرسم غالبا يخلط بين waiting و turnaround، ثم يقضي آخر خمس دقائق يحاول يفهم أين ضاعت الدرجة.

تدريب واحد أنصحك لا تتركه: خذ نفس جدول العمليات وطبقه على أربع خوارزميات في جلسة واحدة. FCFS، SJF، SRTF، ثم RR. حط الرسومات جنب بعض. هنا تبدأ تشوف الفرق بعينك، وليس من تعريف في الشريحة.

Semaphores: اكتب القصة قبل الكود

التزامن هو المكان الذي يبان فيه الفرق بين طالب حافظ وطالب فاهم. wait() و signal() ليستا كلمتين تزين بهما الحل. هما باب وقفل. من يدخل؟ من ينتظر؟ ومن يفتح الباب بعده؟

قبل حل أي سؤال Semaphore، اكتب القصة:

• من ينتج؟
• من يستهلك؟
• ما المورد المشترك؟
• متى يمنع الدخول؟
• متى يسمح بالخروج؟

في Producer-Consumer مثلا، تخيلها كطاولة صغيرة في معمل. المنتج يحط عليها عناصر، والمستهلك يأخذ منها. الطاولة لها عدد أماكن محدود. لو امتلأت، المنتج ينتظر. لو فرغت، المستهلك ينتظر. تحتاج عادة ثلاث أدوات: empty، و full، و mutex.

// المنتج
wait(empty);
wait(mutex);
// أضف عنصرا للمخزن
signal(mutex);
signal(full);

الترتيب هنا ليس تجميليا. لو عكست بعض الأسطر، قد تجعل البرنامج يتجمد. ولو نسيت mutex، يدخل أكثر من thread إلى المخزن في نفس اللحظة. ولو استخدمت empty و full بدون فهم، سيبدو الحل مرتبا على الورق لكنه مكسور من الداخل.

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

مثل دور المنتج والمستهلك بيدك على ورقة. امش خطوة خطوة. من ينتظر؟ من دخل؟ من خرج؟ من نبه الثاني؟ هذه الأسئلة أهم من شكل الكود.

Deadlock و Banker: الجداول لا تكذب

الجمود (Deadlock) سهل لما تسمعه في المحاضرة. كل طرف ماسك شيئا وينتظر شيئا عند الطرف الآخر. واضح.

ثم يجي الواجب بجدول موارد، وتبدأ الحكاية. هل الحالة آمنة؟ هل يوجد safe sequence؟ هل نطبق Banker أو نتكلم عن شروط الجمود فقط؟ هنا لا ينفع الكلام العام.

احفظ شروط الجمود الأربعة، لكن لا تحفظها كقائمة ميتة:

• Mutual Exclusion: المورد لا يستخدمه أكثر من طرف في نفس الوقت
• Hold and Wait: العملية تمسك موردا وتطلب موردا آخر
• No Preemption: لا يمكن سحب المورد بالقوة
• Circular Wait: سلسلة انتظار دائرية

النقطة التي تضيع درجات: الشروط الأربعة لازم تجتمع. وجود شرط واحد لا يعني Deadlock. لا تكتب شرطين وتقول “واضح”. في التصحيح، الواضح لا يأخذ درجة إذا لم تكتبه.

أما Banker Algorithm، فلا تحله من رأسك. اكتب الجداول:

• Available
• Max
• Allocation
• Need = Max - Allocation

ثم ابحث عن عملية يمكن أن تنتهي بالموارد المتاحة. إذا انتهت، أضف مواردها إلى Available. كرر. لو قدرت تنهي كل العمليات، الحالة آمنة. لو توقفت ولا توجد عملية يمكنها الإكمال، الحالة غير آمنة.

الذاكرة و Paging: افصل الأرقام قبل الحساب

في أسئلة الذاكرة، العملية الحسابية نفسها غالبا سهلة. القسمة والباقي وخلاص. المشكلة أنك لا تعرف ماذا يمثل الرقم. هل هو عنوان منطقي؟ رقم صفحة؟ offset؟ frame؟

هنا كثير من الطلاب يخسرون درجة كاملة بسبب كلمة، لا بسبب حساب.

لذلك، قبل أي حساب، اكتب:

logical address = page number + offset
physical address = frame number + offset

لو حجم الصفحة 1024 بايت، والعنوان المنطقي 2500، احسب:

• page number = 2500 / 1024 = 2
• offset = 2500 % 1024 = 452

بعدها ترجع لجدول الصفحات وتبحث عن frame الخاص بالصفحة 2. لو كان frame = 6، يصبح العنوان الفعلي:

physical address = 6 * 1024 + 452 = 6596

هذا النوع من الأسئلة يحب الهدوء. لا تختصر من أول خطوة. اكتب القيم بأسمائها، لأن الخطأ بين page و frame لا يبان إلا في النهاية، وساعتها يكون جدولك كله مبنيا على رقم غلط.

أما Page Replacement، فالأهم هو تتبع الذاكرة خطوة خطوة. FIFO يخرج الأقدم. LRU يخرج الأقل استخداما مؤخرا. Optimal يخرج الصفحة التي ستتأخر أكثر في الاستخدام القادم. لا تخلط بين “الأقدم دخولا” و “الأقل استخداما”. هما ليسا نفس الشيء.

المشروع: قسموا الشغل، بس لازم الكل يفهم الكود

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

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

التقسيم الضعيف معروف: أنت تعمل FCFS، أنا أعمل RR، والثالث يكتب التقرير، وخلاص. هذا ليس فريقا. هذا تجميع ملفات.

التقسيم الأفضل:

• عضو مسؤول عن بنية البيانات الأساسية
• عضو مسؤول عن خوارزميات الجدولة
• عضو مسؤول عن القراءة والاختبار
• عضو مسؤول عن التقرير والتوثيق
• كل عضو يراجع كود عضو آخر مرة واحدة على الأقل

لو المشروع Scheduler، اتفقوا مبكرا على شكل Process:

typedef struct {
    int pid;
    int arrival;
    int burst;
    int remaining;
    int completion;
} Process;

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

كثير من مشاكل المشروع تظهر قبل التسليم بأسبوع، لما تكتشف أن خوارزمية تعمل على input مختلف عن البقية، أو أن التقرير يشرح شيئا لا يطابق الكود. لا تجعل أول اختبار حقيقي للمشروع في الليلة الأخيرة. هذه ليست بطولة، هذه مقامرة.

اكتبوا test cases من الأسبوع الأول. حتى لو كانت ثلاث حالات فقط.

كيف تذاكر عال 227 أسبوعيا؟

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

السبب بسيط: معظم المهارات هنا عضلية. رسم Gantt، تتبع frames، حساب Need، كتابة pseudocode للـ semaphore. هذه الأشياء تتحسن بالتكرار.

اقترح عليك هذا الروتين:

مصادر التدريب لا تتركها للصدفة. اجمع Past Papers من مجموعات الواتساب الخاصة بالدفعة، ومن مواقع دفور وأجدر، ومن صفحة الدكتور على faculty.ksu.edu.sa إذا كان يرفع نماذج تحت “نماذج اختبارات سابقة”. لا تقرأ الإجابة مباشرة. حل على ورقة، وقت نفسك، ثم قارن. هذه الطريقة تكشف أخطاءك أسرع من إعادة قراءة السلايدات ثلاث مرات.

لو عندك وقت إضافي، اربط المادة بما قبلها. عال 212 مهم هنا أكثر مما تتوقع. الطوابير تظهر في الجدولة. القوائم تظهر في إدارة الذاكرة. والأشجار تظهر في أنظمة الملفات. لو أساس تراكيب البيانات ضعيف، راجع دليل عال 212 لتراكيب البيانات قبل أن تلوم نظم التشغيل.

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

أخطاء صغيرة تكلف درجات كبيرة

قبل التسليم بخمس دقائق، لا تفتح شرحا جديدا. راجع هذه القائمة فقط:

• لا تحسب waiting time قبل اكتمال Gantt chart
• لا تنس أن SRTF قابل للمقاطعة
• لا تستخدم mutex حول كود طويل بلا سبب
• لا تخلط بين process و thread في الشرح
• لا تكتب wait و signal بدون تفسير
• لا تنس حساب Need في Banker
• لا تخلط بين page و frame
• لا تعتمد على كود يعمل مرة واحدة فقط
• لا تسلم مشروعك بدون test cases واضحة

الخلاصة

عال 227 ليست مادة مستحيلة. لكنها صريحة جدا. تعطيك نتيجتك بنفس طريقتك.

لو تكتفي بالقراءة، ستتعثر في الواجبات. لو تكتب كودا بدون رسم، ستضيع في الأخطاء. ولو تؤجل Linux و C إلى ليلة التسليم، ستدفع ثمن التأجيل في أبسط سؤال.

ابدأ من السؤال. صنفه. ارسم الحالة. اكتب الخطوات. بعد ذلك فقط افتح المحرر أو ابدأ الحساب النهائي. هذه الطريقة قد تبدو بطيئة في البداية، لكنها تعطيك شيئا أهم من السرعة: ثقة أنك تعرف ماذا تفعل.

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

خذ المادة بجدية من البداية. ليس لأنها سهلة، بل لأنها تستحق التعب.