Update .NET Async - From State Machines to Native Execution

How C# Async/Await Works (The Classic Way)

لما بتيجي تكتب كود C# طبيعي وتستخدم فيه async و await، الكود بيظهر بسيط وسهل انك تقرأه. خلينا نبص على المثال ده:

ودا اللي بنسميه Asynchronous Programming لما بنستخدم الكلمتين دول

public async Task<int> GetData()
{
    // Wait for 1 second
    await Task.Delay(1000);
    return 5;
}

الكود ده في الحقيقة مش بيتنفذ بالشكل البسيط اللي انت شايفه قدامك ده. الـ C# compiler بيحول الكود ده لحاجة أعقد بكتير اسمها State Machine.

تقريبًا، الـ compiler بياخد الميثود بتاعتك وبيحولها لكلاس أو Struct مخفية قريبة من الكود ده:

class GetDataStateMachine : IAsyncStateMachine
{
    int state;
    AsyncTaskMethodBuilder<int> builder;
 
    public void MoveNext()
    {
        if(state == 0)
        {
            var task = Task.Delay(1000);
            state = 1;
            // Register what to do when the task is done
            task.GetAwaiter().OnCompleted(MoveNext);
            return;
        }
 
        // Return the final result
        builder.SetResult(5);
    }
}

اللي بيحصل هنا إن الـ compiler بيخلق من العدم:

1. كلاس أو Struct جديدة تمامًا.
2. منطق State Machine كامل.
3. الـ Builder اللي بيبني ويدير الـ Task.
4. الـ Awaiter اللي بيستنى النتيجة.

كل ده عبارة عن Generated Code بيتعمل من وراك عشان الـ async يشتغل.

---

The Problems with the Classic Approach

الطريقة دي شغالة كويس جدًا ومستقرة من أيام C# 5، لكن مع التطور، ظهرت فيها شوية مشاكل بتأثر على الـ Performance:

1.الـ Allocations كتير (استهلاك للميموري): كل ما بتنادي على async method، الـ runtime بيضطر يعمل حجز (Allocation) في الميموري لشوية حاجات: الـ State machine object، الـ awaiters، والـ tasks. كتر الـ allocations ده بيعمل ضغط على الميموري.

2. الكومبايلر شايل الحمل كله: الـ C# compiler هو اللي بيقوم بكل الشغل التقيل؛ هو اللي بيبني الـ state machine، وهو اللي بيربط الـ awaiters، وهو اللي بيعمل scheduling للـ continuations. الـ runtime نفسه في الحقيقة مش فاهم يعني إيه async، هو مجرد بينفذ الكود اللي الكومبايلر عمله.

3. تعقيد الـ Async Implementation: لو فكرت تفتح الـ Intermediate Language (IL) لكود فيه async، هتتصدم من حجم الكود الضخم والمعقد جدًا اللي اتولد من ميثود كانت في الأصل سطرين!

---

Enter Runtime Async (.NET 11)

من هنا جت الفكرة الجديدة في .NET 11 (واللي بدأت تجاربها في .NET 10). الفكرة ببساطة: بدل ما الـ compiler هو اللي يقعد يبني state machine ضخمة ومعقدة لكل ميثود، ليه مانخليش الـ runtime نفسه يفهم الـ async؟

يعني بدل ما كانت الدورة بتمشي كده: C# Code ⇒ Compiler builds State Machine ⇒ Runtime executes the generated class

بقت بتمشي كده: C# Code ⇒ Compiler lets Runtime manage it ⇒ Runtime Async Engine takes over

هنا، الـ async اتحول لـ First-class citizen جوه الـ runtime نفسه.

Architecture Difference

graph TD
    subgraph Classic Async
        A1[Async Method] --> B1[C# Compiler]
        B1 --> C1[State Machine Class Generated]
        C1 --> D1[Runtime Executes Class]
    end

    subgraph Runtime Async
        A2[Async Method] --> B2[C# Compiler]
        B2 --> C2[Compiler marks method for Runtime]
        C2 --> D2[Runtime Async Engine Manages Execution]
    end

---

Why This Matters

الفكرة دي مش مجرد تغيير معماري، دي ليها تأثيرات ضخمة على تطبيقاتك:

1. الـ Performance أحسن (أداء أعلى): لما الـ runtime يدير العملية، الـ allocations بتقل بشكل ملحوظ، والـ objects اللي بتتكريت بتبقى أقل، وده بيقلل الـ overhead. ده بيفرق جدًا في الـ ASP.NET Core والـ APIs وفي أي High throughput system بيستقبل طلبات كتير.

2. ضغط أقل على الـ Garbage Collector (GC): في الـ Web servers والـ Microservices، كمية الـ async methods اللي بتتنفذ في كل ريكويست مهولة. لو قللنا الـ allocations، هنقلل الشغل اللي الـ GC محتاج يعمله، وبالتالي الأبلكيشن هيبقى أسرع وأكثر استقرارًا.

3. الـ Async هيبقى أخف: في بعض الحالات الحرجة جدًا (Hot paths)، المبرمجين كانوا بيتجنبوا استخدام async بسبب الـ overhead بتاعه. مع الـ Runtime Async، الـ overhead ده هيقل جدًا.

---

Practical API Example

عشان نحس بحجم التغيير، تخيل إنك بتبني API زي ده:

public async Task<User> GetUser()
{
    var user = await db.Users.FindAsync(1);
    return user;
}

الريكويست الواحد اللي بيجي للـ API ده ممكن يمر بـ 10 async calls وكل call فيها 2 await. لو كل await من دول هيكريت State machine و awaiter ويعمل memory allocation، فانت بتتكلم في Load كبير جدًا على السيرفر مع زيادة عدد المستخدمين. الـ Runtime async بيقلل كل الحمل ده بشكل جذري.

---

The Journey: Preview 2 and .NET 10

لازم نوضح إن الـ Runtime Async لسه في بدايته. كانت دي مجرد خطوة أولى لإثبات الفكرة.

لكن الفكرة دي نفسها بدأت تظهر ملامحها في .NET 10. في الإصدار ده، الـ Runtime Async كان متاح كـ Experimental Preview. كنت تقدر تفعله عن طريق إضافة Flags معينة في ملف الـ .csproj بتاعك. المشكلة في .NET 10 إن الـ Core Framework والـ Libraries الأساسية (زي ASP.NET Core) ماكنتش لسه اتعملها Recompile عشان تستخدم التكنولوجيا دي، فكانت الفوائد محدودة بكودك أنت بس.

الهدف على المدى الطويل إن الـ async يبقى Native تمامًا في الـ runtime، ويقرب في أدائه وسرعته من الـ Goroutines في لغة Go، ويسمح للـ runtime إنه يعمل Optimizations أعقد بكتير.

---

What Exactly is a State Machine?

عشان نفهم العظمة اللي كانت بتحصل في الطريقة القديمة واللي بتتغير دلوقتي، خلينا نرجع خطوة لورا ونشرح يعني إيه State Machine ببساطة.

الـ State Machine هو نظام بيتكون من:

1. الـ States (حالات): الحالات المختلفة اللي ممكن النظام يكون فيها.
2. الـ Transitions (انتقالات): النقلة من حالة لحالة تانية بناءً على حدث معين (Event).

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

Traffic Light Analogy

تخيل إشارة المرور، الحالات اللي فيها هي: Red، Yellow، Green. والانتقالات بتكون: Red - Green - Yellow - Red. دي State Machine بسيطة جدًا، لأن فيها States وفيها Transitions.

لو هنكتبها كود هتبقى شبه كده:

enum TrafficLightState
{
    Red,
    Green,
    Yellow
}
 
TrafficLightState state = TrafficLightState.Red;
 
switch(state)
{
    case TrafficLightState.Red:
        state = TrafficLightState.Green;
        break;
 
    case TrafficLightState.Green:
        state = TrafficLightState.Yellow;
        break;
 
    case TrafficLightState.Yellow:
        state = TrafficLightState.Red;
        break;
}

Relation to Async

لما بتكتب كود async زي ده:

public async Task<int> GetNumber()
{
    await Task.Delay(1000);
    return 5;
}

المشكلة إن الميثود دي هتوصل عند الـ await وهتتوقف (Pause)، وبعدين ترجع تكمل شغل بعدين لما الـ Task تخلص. عشان النظام يفتكر هو كان واقف فين بالظبط لما يرجع، لازم يستخدم State Machine.

الـ Compiler بيحول الكود لحالات (States):

• الـ State 0: بداية الميثود.
• الـ State 1: بعد ما الـ Task.Delay يخلص.
• الـ State 2: نهاية الميثود وإرجاع النتيجة.

شكل التنفيذ المبسط بيكون كده:

int state = 0;
 
void MoveNext()
{
    if(state == 0)
    {
        state = 1;
        // Schedule continuation
        Task.Delay(1000).ContinueWith(_ => MoveNext());
        return;
    }
 
    if(state == 1)
    {
        Console.WriteLine(5);
    }
}

كل مرة الـ Task بتخلص، بتنادي على MoveNext()، والـ State machine بتعرف هي المفروض تكمل منين بناءً على قيمة الـ state.

---

State Machine Memory Layout

عشان الـ async method تقدر توقف التنفيذ وترجع الـ thread وتكمل بعدين، لازم تفتكر كل حاجة: كانت واقفة فين، المتغيرات قيمتها إيه، وإيه الخطوة الجاية.

كل ده بيتخزن في State Machine Object في الذاكرة بيبقى شكله التقريبي كده:

{
   "state": 0,
   "local variables": "x = 5",
   "awaiter": "TaskAwaiter object",
   "continuation": "Next step to run"
}

لو عندك ميثود فيها متغيرات زي int x = 5 قبل الـ await، الـ State machine لازم تحفظ قيمة x جواها عشان لما التنفيذ يكمل بعد الـ await يلاقي القيمة موجودة.

الخلاصة: الـ State Machine هي الطريقة اللي الـ .NET بيستخدمها عشان يقسم الكود لمراحل، يحفظ مكان التوقف، ويستكمل التنفيذ بعدين. وبتستخدم في async/await، و yield return، و IAsyncEnumerable.

---

Deep Dive: The Real IL Code

خلينا ندخل أعمق ونشوف الـ Intermediate Language (IL) الحقيقي اللي الـ Compiler بيولده لما بتكتب async/await.

لو كودك الأصلي هو:

public async Task<int> GetNumberAsync()
{
    await Task.Delay(1000);
    return 5;
}

الـ Compiler بيعمل خطوتين كبار:

Step 1: Generating the State Machine Struct

بيولد Struct اسمها عادة بيبدأ بـ <GetNumberAsync>d__0، وبيكون شكلها تقريبًا كده:

private struct GetNumberAsync_StateMachine : IAsyncStateMachine
{
    public int state;
    public AsyncTaskMethodBuilder<int> builder;
    private TaskAwaiter awaiter;
 
    public void MoveNext()
    {
        int result;
        try
        {
            if (state == 0)
            {
                goto AfterAwait;
            }
 
            var task = Task.Delay(1000);
            awaiter = task.GetAwaiter();
 
            if (!awaiter.IsCompleted)
            {
                state = 0;
                // Register continuation and pause
                builder.AwaitUnsafeOnCompleted(ref awaiter, ref this);
                return;
            }
 
        AfterAwait:
            awaiter.GetResult();
            result = 5;
        }
        catch (Exception ex)
        {
            builder.SetException(ex);
            return;
        }
 
        builder.SetResult(result);
    }
 
    public void SetStateMachine(IAsyncStateMachine stateMachine)
    {
        builder.SetStateMachine(stateMachine);
    }
}

Step 2: Rewriting the Original Method

الميثود الأصلية بتاعتك بتتغير وتبقى مجرد Setup للـ State machine:

public Task<int> GetNumberAsync()
{
    var stateMachine = new GetNumberAsync_StateMachine();
    stateMachine.builder = AsyncTaskMethodBuilder<int>.Create();
    stateMachine.state = -1; // Initial state
    
    // Start the state machine
    stateMachine.builder.Start(ref stateMachine);
    
    return stateMachine.builder.Task;
}

Understanding the Key Components:

1. الـ state: بيحدد إحنا فين (مثلاً -1 يعني البداية، 0 يعني بعد أول await).
2. الـ MoveNext(): دي أهم ميثود. الـ runtime بينادي عليها كل مرة الكود بيحتاج يكمل شغل.
3. الـ awaiter: ده الأوبجيكت المسؤول إنه يتابع الـ task ويعرف خلصت ولا لأ ويستكمل التنفيذ.
4. الـ builder (AsyncTaskMethodBuilder): ده المايسترو اللي بيدير العملية؛ بيكريت الـ Task، بيرجع النتيجة في الآخر، وبيدير الـ continuation.

---

Why is This So Heavy?

لو ركزت في اللي بيحصل، هتلاقي الـ Flow بيمشي كده: Call Method ⇒ Create StateMachine ⇒ MoveNext() ⇒ Reach await ⇒ Register continuation ⇒ Method returns ⇒ Task finishes ⇒ MoveNext() again ⇒ Return result.

كل الخطوات دي بتتطلب إنتاج Struct، استخدام Builder، إدارة State، وتسجيل Continuation. ده بيعمل Overhead كبير جدًا، وعشان كده الـ Runtime Async في .NET 11 بيحاول يمسح كل التعقيد ده ويخلي الـ runtime يدير القصة دي مباشرة بـ Objects و Allocations أقل.

---

ASP.NET Core & The Thread Pool Magic

Asynchronous Programming

بما إننا فهمنا الـ Async شغال إزاي، خلينا نربطه بأهم حاجة بتفرق معاك كـ Backend Engineer: إزاي الـ ASP.NET Core بيقدر يخدم آلاف الريكويستات في نفس الوقت باستخدام الميكانيزم ده.

لو افترضنا إن معندناش async، والـ API بيكلم Database بتاخد 100ms عشان ترد. الـ Thread بتاع السيرفر هيفضل واقف مستني (Blocked) الـ 100ms دول وهو مش بيعمل أي حاجة مفيدة. لو عندك 200 Thread في السيرفر، وجالك 200 ريكويست في نفس اللحظة بيكلموا الـ DB، السيرفر كله هيقف (Thread Starvation).

لكن مع الـ async/await، السحر بيحصل: لما الكود بيوصل لـ await db.Users.FirstAsync();، الـ runtime بيسجل الـ continuation، وبيسيب (Release) الـ Thread فورًا. الـ Thread ده بيرجع للـ Thread Pool ويبقى جاهز يخدم ريكويست تاني لعميل تاني.

The Restaurant Analogy

• بدون Async: الجرسون (Thread) بياخد طلبك، يروح يديه للمطبخ، ويفضل واقف قدام المطبخ ربع ساعة مستني الأكل يجهز عشان يجيبهولك. في الوقت ده محدش تاني في المطعم بيعرف يطلب.
• مع Async: الجرسون بياخد طلبك، يرميه للمطبخ، ويروح ياخد طلب من ترابيزة تانية. لما أكلك يجهز، المطبخ بيرن جرس (Task Completed)، فأي جرسون فاضي بييجي ياخد الأكل ويوصلهولك.

ده السبب الرئيسي إن ASP.NET Core يقدر يخدم 10,000 ريكويست باستخدام 200 Threads بس، لأن معظم الوقت التطبيق بيكون مستني (Waiting I/O) زي داتابيز أو Network أو File system. وبما إن مفيش SynchronizationContext في ASP.NET Core، أي Thread فاضي يقدر يكمل الميثود بعد الـ await.

---

Advanced Under The Hood: Suspending Without a State Machine

السؤال اللي بيطرح نفسه للمهندسين الثقال: إزاي الـ runtime بيقدر يوقف (Suspend) الميثود من غير ما يبني State Machine كلاس أصلاً؟

هنا بتيجي العبقرية. الـ .NET بيستخدم تكنيك أقرب للي بيحصل في لغات زي Go و Rust: بدل ما ينقل كل المتغيرات لـ Heap-allocated object (الـ State Machine)، الـ Runtime بيعتمد على تقنية اسمها Stack Spilling واستخدام الـ Async Thunks.

اللي بيحصل إن الكود بيفضل شغال على الـ Call Stack العادي. لما بيقابل await ويحتاج يتوقف، الـ Runtime بياخد “لقطة” (Snapshot) من الفريم الحالي بتاع الميثود دي على الـ Stack (بمتغيراتها وكل حاجة) وبينقلها (Spills it) لـ Heap-allocated memory خفيفة جدًا (Continuation frame). ولما الـ Task تخلص، الـ Runtime بيرجع يـ Restore الفريم ده تاني على الـ Stack عن طريق الـ Async Thunks ويكمل تنفيذ كأن مفيش حاجة حصلت.

الأسلوب ده بيخلي الـ Execution سريع جدًا، والـ Allocations بتحصل بس لو فعلاً الميثود احتاجت تستنى (لو خلصت Synchronously مش بيحصل أي Allocation نهائي).

---

More in .NET 11

.NET 11: Runtime Async V2

في التحديث الجديد (.NET 11 Preview 2)، التطور بقى ملحوظ جدًا. الـ Runtime Async دخل مرحلة (V2)، وبدل ما كان الكومبايلر بيبني الـ Classes، الـ runtime بقى بيدير عملية الـ Suspend والـ Resume بنفسه.

Opting In

لأن الميزة لسه في مرحلة الـ Preview، لازم تفعلها بإيدك في ملف الـ .csproj:

<PropertyGroup>
  <Features>runtime-async=on</Features>
  <EnablePreviewFeatures>true</EnablePreviewFeatures>
</PropertyGroup>

Cleaner Live Stack Traces

أكتر فرق هتشوفه بعينك هو الـ Stack Traces (وقت الـ Debugging والـ Profiling). في الطريقة القديمة، لو عندك ميثودز بتنادي بعض: Main ⇒ OuterAsync ⇒ MiddleAsync ⇒ InnerAsync، الـ Stack Trace كان بيبقى مليان زبالة (Frames كتير من AsyncMethodBuilderCore.Start و MoveNext).

مع الـ Runtime Async، الـ Stack trace بيبقى نظيف جداً ومباشر:

   at Program.<<Main>$>g__InnerAsync|0_2() in Program.cs:line 24
   at Program.<<Main>$>g__MiddleAsync|0_1() in Program.cs:line 14
   at Program.<<Main>$>g__OuterAsync|0_0() in Program.cs:line 8
   at Program.<Main>$(String[] args) in Program.cs:line 3
   at Program.<Main>(String[] args)

مفيش أي State machine infrastructure ظاهرة! (خلي بالك إن الـ Exception Stack Traces كانت كده كده نظيفة بسبب الـ ExceptionDispatchInfo، التحسن هنا في الـ Live stack traces وأنت بتعمل Debugging).

Debugging Improvements

دلوقتي الـ Breakpoints بتشتغل صح جوه الـ runtime-async methods. الـ Debugger اتعلم إزاي يتعرف على حاجة اسمها async thunks ويعملها Mapping للكود الأصلي بتاعك، فبتقدر تعمل Step Over للـ await بسلاسة بدون ما تتنطط في كود الـ infrastructure المولد.

---

JIT Improvements in Preview 2

تحديث .NET 11 Preview 2 جاب معاه تحسينات قوية جدًا في الـ JIT Compiler:

1. Bounds Check Removal:

لو الـ JIT قدر يتأكد إن الشرط i + constant < length دايماً متحقق، بيشيل الـ Bounds check تماماً. ده بيقلل الـ Branching وبيسرع اللوبس جدًا.

2. Redundant Checked Context Removal:

في الـ checked blocks (اللي بتراقب الـ Overflow في العمليات الحسابية)، لو الـ JIT أثبت إن القيم مستحيل تعمل Overflow، بيلغي الـ check ده عشان يحسن الأداء.

3. Devirtualization in ReadyToRun (R2R):

في الـ OOP، الـ Virtual calls بتحتاج Runtime dispatch (تحديد انهي ميثود هتتنفذ وقت التشغيل). دلوقتي الـ R2R (Ahead-of-Time compilation) بقى يقدر يعمل Devirtualize للميثودز الجينيريك الغير مشتركة ويناديها بشكل مباشر، وده أسرع بكتير.

4. SVE2 Intrinsics:

إضافة دعم لتعليمات ARM SVE2 الخاصة بالـ SIMD والـ Math-heavy workloads.

---

VM Improvements

Virtual Machine - CLR

الـ Virtual Machine (CLR) أخدت نصيبها من التحسينات:

1. Cached Interface Dispatch on Non-JIT Platforms:

على منصات زي iOS اللي مفهاش JIT، المناداة على Interfaces كانت بتستخدم مسار بطيء (Generic fixup). دلوقتي بقوا يستخدموا Cached dispatch بشكل افتراضي، وده سرّع الأداء لدرجة توصل لـ 200 ضعف في الكود المعتمد على الـ Interfaces بكثرة.

2. Guid.NewGuid() on Linux:

بدل ما الـ runtime كان بيقرأ من الفايل /dev/urandom، بقى بيستخدم الـ getrandom() System call مع Caching. النتيجة؟ تسريع بنسبة 12% لإنتاج الـ GUIDs على لينكس.

3. CoreCLR iOS-like Mode:

أضافوا Flag جديد --dynamiccodecompiled false بيخلي الـ CoreCLR على الديسكتوب يتصرف كأنه شغال على iOS (بيقفل الـ JIT ويشغل الـ Interpreter). ده بيساعدك تتيست بيئة الـ AOT وأنت على جهازك من غير ما تضطر تعمل Deploy على موبايل.

---

Notes

• الـ Task vs ValueTask: وإحنا بنتكلم عن تقليل الـ Allocations، الـ .NET كان قدم ValueTask قبل كده كحل لتقليل الحجز في الذاكرة لو الـ Async method هترجع النتيجة بشكل متزامن (Synchronously). الـ Runtime Async بياخد الفكرة دي ليفل أعلى وبيقلل الـ Overhead حتى في الـ Asynchronous paths الحقيقية.
• الـ System.Linq.AsyncEnumerable: من التغييرات القوية في .NET 10 المرتبطة بالـ Async، إن مايكروسوفت أضافت System.Linq.AsyncEnumerable كجزء Native من الـ .NET. قبل كده، لو كنت عايز تستخدم LINQ مع IAsyncEnumerable، كنت بتضطر تنزل باكيدج خارجية (System.Linq.Async من Ix.NET). من أول .NET 10، الدعم ده بقى مدمج، وده بيعكس توجه مايكروسوفت إن الـ Async يبقى جزء متأصل (First-class) في المنصة والـ Runtime.