أساسيات الـ Operating System

#اختياري: Process و Thread و TaskBonusOptional: processes, threads and tasks

اختياري بس بيفرق: مش هيتسأل فيه في كل انترفيو، بس معرفته بتعمّق فهمك وبتميّزك عن غيرك.

الـ CPU ينفذ التعليمات؛ logical CPU هو مسار تنفيذ ظاهر للـ OS وقد يكون نواة فعلية أو مسارًا منطقيًا. الـ scheduler يوزع وقت التنفيذ بين threads الجاهزة. كلمة «جاهزة» تعني إنها تقدر تكمل لو اتخصص لها CPU، عكس thread منتظرة I/O أو قفل. هنستخدم الفرق ده لما نفسر async لاحقًا.

الـ OS بيحتاج يفصل برامج عن بعض ويوزع وقت الـ CPU. الـ process حاوية موارد وعنوان ذاكرة افتراضي؛ الـ thread مسار تنفيذ جوه process وليه registers و stack. threads في نفس process بتشارك heap وموارد، فمحتاجين synchronization. الـ Task في .NET بتمثل عملية واكتمالها، مش OS thread جديدة.

CPU-bound Tasks غالباً بتشتغل على ThreadPool؛ I/O Tasks بتعتمد على APIs والـ OS. process منفصلة مفيدة للعزل أوتشغيل برنامج خارجي، مش بديل رخيص لكل method call.

#اختياري: شكل ذاكرة ProcessBonusOptional: process memory layout

اختياري بس بيفرق: مش هيتسأل فيه في كل انترفيو، بس معرفته بتعمّق فهمك وبتميّزك عن غيرك.

قبل الخريطة: virtual address عنوان يستخدمه البرنامج، والنظام يربطه بصفحة ذاكرة فعلية أو backing storage عند الحاجة. managed memory يديرها .NET GC؛ native memory تخصصها مكتبات أو استدعاءات النظام ولا يجمعها GC ككائن .NET. الـ JIT compiler يحول IL إلى تعليمات المعالج وقت التشغيل، وASLR يغيّر عناوين الذاكرة بين التشغيلات لأسباب أمنية. الشكل التالي تقريبي للتعلّم.

علشان تفهم memory growth، فرّق بين مناطق العملية بدل اعتبارها heap واحدة. الشكل ده تعليمي؛ ترتيب العناوين الفعلي بيتغير بالـ OS والـ runtime والـ ASLR.

value type مش معناه stack دائماً: field جوه object بيتخزن inline جواه، و boxing بيعمل managed object، و async state ممكن تعيش في heap. المثال .NET console app مع using System.Diagnostics;، والأرقام لقطة تقريبية مش memory profiler.

using System.Diagnostics;

using var process = Process.GetCurrentProcess();
process.Refresh();
Console.WriteLine($"Resident bytes: {process.WorkingSet64}"); // (1)
Console.WriteLine($"Managed estimate: {GC.GetTotalMemory(false)}"); // (2)

لو managed heap ثابتة و working set بتكبر، فتش على native allocations و stacks و mapped files، مع فهم اختلاف المقاييس بين أنظمة التشغيل.

#اختياري: Scheduling و Context switchingBonusOptional: scheduling and context switching

اختياري بس بيفرق: مش هيتسأل فيه في كل انترفيو، بس معرفته بتعمّق فهمك وبتميّزك عن غيرك.

عدد threads الجاهزة غالباً أكبر من logical CPUs. scheduler بيختار مين يشتغل، وممكن يعمل preemption علشان يدي غيره فرصة. time slice و priority policies بتختلف حسب OS والـ scheduling class؛ مش وعد بوقت ثابت ولا ضمان ترتيب عادل تماماً.

1. thread تشتغل لحد block أو yield أوقرار preemption.
2. الـ OS يحفظ execution context زي registers ومكان التنفيذ.
3. يشغل thread تانية؛ caches و TLB locality ممكن تتأثر. تغيير process ممكن يضيف تكلفة address-space handling.
4. لما الأولى ترجع، بتكمل من حالتها المحفوظة، مش من أول method.

context switch ليه direct cost وكلفة غير مباشرة من cache misses، بس مفيش رقم ثابت صالح لكل جهاز. زيادة threads مش بالضرورة زيادة throughput؛ ممكن تزود contention و memory و switching. thread priority العالية ممكن تجوّع غيرها أوتدخل في priority inversion؛ مش علاج لبطء query.

#اختياري: Mutex و Semaphore و SpinlockBonusOptional: mutexes, semaphores and spinlocks

اختياري بس بيفرق: مش هيتسأل فيه في كل انترفيو، بس معرفته بتعمّق فهمك وبتميّزك عن غيرك.

مشاركة resource محتاجة قواعد دخول، لكن اختيار primitive غلط ممكن يحول كل البرنامج لطابور. mutex يسمح بمالك واحد، و semaphore بيسمح بعدد محدد من الداخلين. spinlock بيفضل يلف على CPU بدل النوم، فمناسب فقط لانتظار بالغ القصر بعد قياس، مش حول I/O.

fragment داخل class بيحد الشغل المتزامن؛ محتاج Dispose للـ semaphore عند انتهاء عمر الخدمة وبعد انتهاء مستخدميها.

private readonly SemaphoreSlim slots = new(4, 4);

public async Task RunLimitedAsync(Func<Task> work, CancellationToken ct)
{
    await slots.WaitAsync(ct); // (1)
    try
    {
        await work(); // (2)
    }
    finally
    {
        slots.Release(); // (3)
    }
}

مفيش await جوه lock؛ استخدم primitive مناسبة للسياق، وماتخلطش mutex مملوكة لـ thread مع continuation ممكن تكمل على thread تانية.

#اختياري: Deadlock و شروط CoffmanBonusOptional: deadlock and the Coffman conditions

اختياري بس بيفرق: مش هيتسأل فيه في كل انترفيو، بس معرفته بتعمّق فهمك وبتميّزك عن غيرك.

deadlock بيحصل لما أطراف تستنى موارد ماسكها بعض ومحدش يقدر يتقدم. في النموذج الكلاسيكي، الأربع شروط لازم يجتمعوا؛ وجودهم لوحده مش معناه إن deadlock حصل بالفعل.

لو نقل رصيد بين حسابين محتاج قفلين، رتبهم بـ account ID في كل المسارات. timeout يدي فرصة تفشل أوتعيد المحاولة، لكنه مش بيحل التصميم تلقائياً؛ لازم تفك اللي ماسكه وتتعامل مع partial work. starvation مختلف: شغل مش بياخد فرص كفاية؛ livelock فيه نشاط مستمر من غير تقدم مفيد.

#اختياري: Virtual memory و Paging و Page faultsBonusOptional: virtual memory, paging and page faults

اختياري بس بيفرق: مش هيتسأل فيه في كل انترفيو، بس معرفته بتعمّق فهمك وبتميّزك عن غيرك.

كل process بتشوف address space افتراضية؛ hardware والـ OS بيترجموا صفحاتها لـ physical frames أو backing storage. الحجز الافتراضي مش معناه RAM فعلية مستخدمة. الـ OS بيستعمل paging للحماية والمشاركة والتحميل عند الحاجة، مش مجرد تعويض نقص RAM.

1. برنامج يلمس virtual address، و translation تتراجع عبر TLB أو page tables.
2. لو الصفحة مش حاضرة أوالوصول مخالف للصلاحيات، يحصل page fault ويتدخل الـ OS.
3. valid demand page ممكن تتجهز بzero-fill أو mapping موجود، من غير disk I/O؛ minor fault مش خطأ تطبيق بالضرورة.
4. لو محتاجة قراءة من storage، الانتظار أغلى؛ ده major fault بالمصطلح الشائع على Linux.
5. invalid access ممكن يتحول لفشل للعملية، بدل تحميل صفحة.

working set أو resident set هو الصفحات الموجودة حالياً في RAM للعملية، بتفاصيل مختلفة حسب OS. resident pages مش كلها unique أو private. ضغط الذاكرة وكثرة paging ممكن يسبب thrashing: وقت أكتر بيتصرف في نقل صفحات بدل شغل مفيد.

تابع process metrics و container metrics مع بعض؛ file cache ممكن تتحسب على cgroup، و swap ممكن تكون مقفولة أومحدودة. زيادة virtual memory مش دليل leak لوحدها، و page fault مش معناها disk read دايماً.

#اختياري: GC علاقتها بالـ OS و Server GCBonusOptional: the GC, the OS and Server GC

اختياري بس بيفرق: مش هيتسأل فيه في كل انترفيو، بس معرفته بتعمّق فهمك وبتميّزك عن غيرك.

الـ GC بتدير عمر managed objects فوق نظام الذاكرة الافتراضية؛ الـ OS بيدير mappings والصفحات والموارد على مستوى العملية. لما GC تجمع object مش لازم working set تنزل فوراً؛ runtime ممكن تحتفظ بذاكرة لاستخدام لاحق، والـ OS له قراراته في residency.

ASP.NET Core web SDK بيطلب Server GC افتراضياً، لكن افحص الوضع الفعلي بـ GCSettings.IsServerGC. runtime ممكن يتكيف مع CPU والـ memory limits، والتفاصيل بتتطور؛ ماتحفظش «heap ثابت لكل CPU» كقانون مطلق.

managed heap جزء من process footprint؛ native buffers و thread stacks و JIT code كمان موجودين. GC heap hard limit مش cap لكل process memory. سيب headroom للـ native memory والـ OS accounting؛ container ممكن تتقتل قبل ما تشوف OutOfMemoryException managed. Workstation و Server GC.

#اختياري: I/O models و epoll و kqueue و IOCPBonusOptional: I/O models, epoll, kqueue and IOCP

اختياري بس بيفرق: مش هيتسأل فيه في كل انترفيو، بس معرفته بتعمّق فهمك وبتميّزك عن غيرك.

لو كل socket مستنية thread، عدد connections الكبير هيستهلك stacks و scheduler. blocking I/O بيوقف thread لحد نتيجة؛ non-blocking I/O بيرجع بسرعة لو مفيش داتا؛ multiplexing بيسمح بمراقبة sockets كتير من غير thread لكل واحدة.

.NET socket async APIs بتخفي كتير من الاختلافات. await بتتعامل مع اكتمال العملية؛ مش هي اللي بتنفذ epoll بنفسها. مش كل async API معناها zero blocked threads تحتها: file I/O وسلوك providers والـ OS ممكن يختلفوا.

المثال fragment في async method، مع using System.Net.Sockets;. socket متصلة بالفعل و ct متاح. ده read واحدة، مش protocol framing كامل.

byte[] buffer = new byte[4096];
int read = await socket.ReceiveAsync(buffer.AsMemory(), SocketFlags.None, ct); // (1)
if (read == 0) // (2)
    return;
Console.WriteLine($"Received {read} bytes"); // (3)

في edge-triggered epoll محتاج تتعامل صح مع nonblocking reads لحد EAGAIN؛ التطبيق العادي يفضل يستخدم .NET APIs بدل إعادة بناء event loop. مرجع epoll.

#اختياري: File descriptors و Handles و LimitsBonusOptional: file descriptors, handles and limits

اختياري بس بيفرق: مش هيتسأل فيه في كل انترفيو، بس معرفته بتعمّق فهمك وبتميّزك عن غيرك.

ملف مفتوح أو socket مش مجرد managed object؛ وراه OS resource. على Unix، file descriptor رقم في process table يشير لـ open resource؛ على Windows فيه handles مع access rights وآليات خاصة. المقبض مش pointer عادي ولاid دائم؛ أرقامه ممكن تتعاد بعد الإغلاق.

نسيان Dispose ممكن يستهلك limits حتى لو managed heap صغيرة. GC finalizers ممكن تعمل cleanup لاحقاً لبعض wrappers، لكن التوقيت مش مضمون، وبعض الموارد مش ليها finalizer أصلاً. استخدم using أو await using و SafeHandle في native interop المناسب.

المثال كامل لـ console app بيكتب file؛ UTF-8 و line ending صريحين علشان النتيجة مستقلة عن المنصة.

using System.Text;

var path = Path.Combine(Path.GetTempPath(), $"invoice-{Guid.NewGuid():N}.txt");
await using (var file = new FileStream(path, FileMode.CreateNew,
    FileAccess.Write, FileShare.None, 4096, FileOptions.Asynchronous)) // (1)
{
    var bytes = Encoding.UTF8.GetBytes("Invoice total: 100 EGP\n");
    await file.WriteAsync(bytes); // (2)
} // (3)
Console.WriteLine(path);

عند «too many open files»، افحص عدد descriptors ومصادرها و limits والـ leak قبل رفع الحد. sockets و pipes و epoll instances كمان بتستهلك descriptors. الـ diagnostic tools نفسها ممكن تكون غايبة من minimal container، فخطط للتشخيص من host أو debug image.

#اختياري: Signals و Graceful shutdown في containersBonusOptional: signals and graceful container shutdown

اختياري بس بيفرق: مش هيتسأل فيه في كل انترفيو، بس معرفته بتعمّق فهمك وبتميّزك عن غيرك.

deploy بيوقف process وهي ممكن تكون بتعالج طلب. Linux container runtime عادة بيبعت SIGTERM، وبعد grace period ممكن SIGKILL. Generic Host مع ConsoleLifetime بيبدأ shutdown عند SIGTERM؛ SIGKILL مش قابل للالتقاط ولا يضمن finally. shell wrapper ممكن يمنع وصول signal لو مش بيعمل exec صح.

المثال Program.cs كامل لـ ASP.NET Core 10. notification callback قصيرة للـ logs؛ التنضيف async الحقيقي يتحط في hosted service StopAsync أو disposal، مع deadline.

var builder = WebApplication.CreateBuilder(args);
builder.Services.Configure<HostOptions>(options =>
    options.ShutdownTimeout = TimeSpan.FromSeconds(20)); // (1)
var app = builder.Build();

app.Lifetime.ApplicationStopping.Register(() => // (2)
    app.Logger.LogInformation("Shutdown requested; draining work"));

app.MapGet("/", () => "Ready");
await app.RunAsync(); // (3)

اسحب instance من routing، وخلّي processing idempotent لأن crash ممكن يحصل في أي وقت. shutdown مش بديل عن durable queue و transactions. Generic Host lifecycle.

#اختياري: cgroups و Namespaces و Windows مقابل LinuxBonusOptional: cgroups, namespaces, Windows and Linux

اختياري بس بيفرق: مش هيتسأل فيه في كل انترفيو، بس معرفته بتعمّق فهمك وبتميّزك عن غيرك.

Linux containers مبنية على mechanisms في kernel، مش نسخة OS كاملة لكل container. namespaces بتغير رؤية resources زي process IDs والشبكة والـ mounts؛ cgroups بتجمع processes لحساب الموارد وتحديد CPU و memory وغيرها. namespaces مش resource limits، و cgroups مش network isolation.

CPU limit ممكن يعمل throttling حتى لو الـ host عنده CPU فاضية خارج الحصة. memory limit ممكن تؤدي لـ OOM kill حسب الظروف. راقب cgroup usage مش managed heap بس، وماتكتبش paths ثابتة لقراءة cgroup files من غير فهم version و mount layout. مرجع cgroup v2.

متفترضش إن كل Windows filesystem بنفس case rules أوكل Linux filesystem بنفس capabilities. اختبر على deployment target في CI، وماتعتمدش على drive letters أو registry أو Windows-only libraries في كود لازم يشتغل على Linux. containers مش عزل VM؛ kernel مشتركة، وتقليل privileges و capabilities مهم.