أساسيات COM STA/MTA - نماذج مؤشّرات الترابط وكيفية تجنّب حالات التعليق (Hang)

يصعب تجنّب STA و MTA حالما تبدأ بالتعامل مع COM من شيفرة Windows أو من .NET. أكثر الأسئلة شيوعاً هي: لماذا تكون مؤشّرات ترابط واجهة المستخدم STA في العادة، وماذا يحدث حين يَعبُر استدعاءٌ ما بين Apartments، ولماذا قد يَتعلّق البرنامج رغم أنّ الشيفرة تبدو سليمة.

المحتويات

1. الخلاصة المختصرة
2. أنماط الاستدعاء في نموذج Apartment
   • 2.1. النمط 1: الاستدعاء داخل مؤشّر ترابط STA نفسه
   • 2.2. النمط 2: الاستدعاء داخل MTA نفسه
   • 2.3. النمط 3: عبور Apartments
   • 2.4. تصوّر تقريبي لتكلفة Marshaling
3. STA (Single-Threaded Apartment)
   • 3.1. لماذا تستخدم مؤشّرات ترابط واجهة المستخدم STA
4. MTA (Multi-Threaded Apartment)
5. أين يُحسم STA / MTA
   • 5.1. STA / MTA في .NET
6. مثال ملموس على تعليق ناتج عن سوء التعامل مع STA
   • 6.1. وضع شائع
   • 6.2. ما الذي يحدث فعلاً
   • 6.3. شيفرة وهمية لنمط الفشل النموذجي
   • 6.4. النقاط الجوهرية للتجنّب
   • 6.5. ماذا يعني فعلاً «تشغيل حلقة الرسائل»؟
   • 6.6. اتّجاه أكثر سلامة (تقريباً)
   • 6.7. نمط تعليق آخر: استدعاء عكسي أثناء استدعاء متزامن
7. إرشادات عملية تقريبية
8. الخلاصة
9. مراجع

عند استخدام COM، فإنّ مؤشّر الترابط الذي يعمل عليه الكائن ليس معرفةً اختياريّة.
ويقع في صميم ذلك نموذج Apartment (STA / MTA).

إنّ STA و MTA هما نموذجَا مؤشّرات ترابط مُعرَّفان من أجل COM.
وهما ليسا الشيء نفسه الذي يُقصد به مؤشّرات ترابط Windows العامّة. بل وُجدا لتحديد قواعد استدعاء كائنات COM.

يُنظِّم هذا المقال العلاقة بين STA و MTA و COM عبر مخطّطات بيانية، ويربط ذلك مباشرةً بـ سبب حدوث حالات التعليق.

1. الخلاصة المختصرة

• قواعد استدعاء كائن COM تتحدّد بحسب Apartment الذي ينتمي إليه
• يُفهَم STA على أبسط نحو بأنّه Apartment واحد لكلّ مؤشّر ترابط
• يُفهَم MTA على أبسط نحو بأنّه عدّة مؤشّرات ترابط تتشارك Apartment واحداً
• حين تَعبُر الاستدعاءات بين Apartments، يقوم COM بعملية Marshaling عبر بنية Proxy / Stub

2. أنماط الاستدعاء في نموذج Apartment

ثمّة ثلاثة أنماط عامّة لاستدعاء كائنات COM.

2.1. النمط 1: الاستدعاء داخل مؤشّر ترابط STA نفسه

إذا كان كلٌّ من المُستدعِي والكائن يعيشان على مؤشّر ترابط STA نفسه، فإنّ الاستدعاء مباشر ولا يكاد يُحدث أيّ تكلفة Marshaling.

flowchart LR
    subgraph STA[STA thread]
        Caller[Caller code]
        Obj[COM object]
        Caller -->|Direct call| Obj
    end

2.2. النمط 2: الاستدعاء داخل MTA نفسه

داخل MTA نفسه، يمكن أيضاً لعدّة مؤشّرات ترابط أن تستدعي مباشرةً.
لكن في المقابل، يجب أن يكون الكائن نفسه مصمَّماً ليكون آمن مؤشّرات الترابط (thread-safe).

flowchart LR
    subgraph MTA[MTA - one apartment]
        Thread1[Worker thread 1]
        Thread2[Worker thread 2]
        Obj[COM object]
        Thread1 -->|Direct call| Obj
        Thread2 -->|Direct call| Obj
    end

2.3. النمط 3: عبور Apartments

بين Apartments المختلفة، يُمرِّر COM الاستدعاء عبر آليّة Proxy / Stub.
وبالنسبة إلى الواجهات القياسية، يتولّى زمن تشغيل COM ذلك نيابةً عنك في الغالب.

ملاحظة مهمّة: هذا لا يعني أنّ شيفرة Proxy / Stub «تُولَّد تلقائياً لكلّ شيء».
لكن في كثير من المشاريع الفعلية، لا تحتاج إلى توليدها صراحةً.

ومن ثَمّ، فإنّ الموضع الذي تَبرز فيه أهمّية شيفرة Proxy / Stub المولَّدة صراحةً بـ MIDL هو واجهات IUnknown المخصّصة التي لا تستخدم Automation.
وهذا أقلّ شيوعاً ممّا يظنّه كثيرون في الاستخدام اليومي لـ COM من .NET أو من لغات السكربتة.

flowchart LR
    subgraph STA[STA thread]
        StaCaller[Caller code]
    end

    subgraph RT[COM runtime]
        Proxy[Proxy]
        RPC[RPC / transfer]
        Stub[Stub]
        Proxy --> RPC --> Stub
    end

    subgraph MTA[MTA thread]
        MtaObj[COM object]
    end

    StaCaller -->|Call| Proxy
    Stub -->|Forward| MtaObj

النقطة الجوهرية:
ما إن تَعبُر بين Apartments، تظهر تكلفة Marshaling.
وإذا كان الاستدعاء عالي التكرار، فإنّ هذه التكلفة تصير اعتباراً تصميمياً حقيقياً.

2.4. تصوّر تقريبي لتكلفة Marshaling

ما يلي هو تصوّر تقريبي فحسب، وليس قياساً أداءً (benchmark). والكلفة الفعلية تتغيّر كثيراً تبعاً لتفاصيل التنفيذ ومدى تعقيد الوسائط.

الحدس النسبي:

• Apartment نفسه: مثل استدعاء على مستوى الذاكرة الاعتيادي
• Apartment مختلفة: أقرب إلى حدّ بمستوى استدعاء نظام (system call)
• عملية مختلفة: أقرب إلى RPC على المضيف المحلّي أو تواصل بين عمليّات ثقيل

إذا استدعيتَ شيئاً عشرة آلاف مرّة داخل حلقة، يصبح هذا الفارق ظاهراً جدّاً.

3. STA (Single-Threaded Apartment)

STA هو النموذج الذي يمتلك فيه مؤشّر ترابط واحد Apartment واحداً.

• كائنات COM داخل ذلك Apartment تُنفَّذ أساساً على ذلك المؤشّر
• إذا استدعاها مؤشّر ترابط آخر، فإنّ COM يُحوّل الاستدعاء عبر طابور الرسائل / RPC
• مؤشّرات ترابط واجهة المستخدم في WinForms / WPF كثيراً ما تستخدم STA لأنّ واجهة المستخدم نفسها تتّصف أصلاً بألفة قويّة لمؤشّر ترابط واحد ولديها حلقة رسائل

3.1. لماذا تستخدم مؤشّرات ترابط واجهة المستخدم STA

تتطابق فلسفة تصميم مؤشّرات ترابط واجهة المستخدم مع STA إلى حدّ بعيد.

• عناصر تحكّم واجهة المستخدم ليست آمنة لمؤشّرات الترابط بشكل عامّ
  لا يمكن التعامل مع الأزرار وحقول النصّ وسائر عناصر واجهة المستخدم بأمان إلّا من المؤشّر الذي أنشأها
• STA يفترض كذلك ألفةً قوية لمؤشّر ترابط
  كائنات COM تعمل مباشرةً على المؤشّر المالك لها فقط
• مؤشّرات ترابط واجهة المستخدم تُشغّل دائماً حلقة رسائل
  هذا مطلوب لأحداث النوافذ، ويتطابق أيضاً مع افتراض message-pump في STA

ولهذا فإنّ مؤشّرات ترابط واجهة المستخدم في WinForms و WPF هي STA افتراضياً.

والمقابل هنا أنّ STA يتميّز بألفة قوية للمؤشّر، ولذلك يَسهل ظهور ازدحام إن اعتمدت عليه أمور كثيرة في وقت واحد.

4. MTA (Multi-Threaded Apartment)

MTA هو النموذج الذي تتشارك فيه عدّة مؤشّرات ترابط Apartment واحداً.

• قد تُستدعى كائنات COM من عدّة مؤشّرات ترابط في الوقت ذاته
• يجب أن يكون تنفيذ الكائن نفسه آمناً لمؤشّرات الترابط
• وهو أنسب للمعالجة من نمط الخوادم وللمعالجات الخلفية

والموازنة هنا معكوسة بالنسبة إلى STA:
يقدّم MTA توازياً أعلى، لكنّ التنفيذ يتحمّل مسؤوليّة أكبر.

5. أين يُحسم STA / MTA

تُحسم Apartments الخاصّة بـ COM لكلّ مؤشّر ترابط، وذلك عند التهيئة.

• CoInitialize / CoInitializeEx يحدّد Apartment لذلك المؤشّر
• يستخدم STA COINIT_APARTMENTTHREADED
• يستخدم MTA COINIT_MULTITHREADED

5.1. STA / MTA في .NET

تكشف .NET ذلك عبر [STAThread] و [MTAThread] و ApartmentState، لكنّ هذه ليست في الحقيقة سوى وسائل لإعداد نموذج Apartment الخاصّ بـ COM.

• [STAThread]
  يُطبَّق على دالة Main (نقطة الدخول)؛ ويهيّئ COM ذلك المؤشّر بوصفه STA حين يُستخدم COM
• [MTAThread]
  الفكرة نفسها لكن من أجل MTA
• Thread.SetApartmentState(ApartmentState.STA)
  يُستخدم للمؤشّرات الإضافية التي تنشئها يدوياً، ويجب ضبطه قبل بدء المؤشّر

تفاصيل مهمّة:

• [STAThread] لا يُحدث أثراً عمليّاً ما لم يُستخدَم COM فعلاً
• [STAThread] لا يؤثّر على المؤشّرات الإضافية
• بعد تهيئة Apartment لمؤشّر ترابط، لا يمكنك تغييره لاحقاً

ولذلك، في .NET كذلك، التهيئة الأولى لـ COM هي كلّ شيء.

6. مثال ملموس على تعليق ناتج عن سوء التعامل مع STA

البِنية التالية طريقة واقعية جدّاً لخلق حالة تعليق.

6.1. وضع شائع

• تُنشئ مؤشّر ترابط STA خلفي وتُنشئ كائن COM هناك
• ذلك المؤشّر لا يُشغّل حلقة رسائل
• مؤشّر ترابط آخر يستدعي كائن COM

يمكن أن يكون المؤشّر الآخر STA أو MTA. النقطة الجوهرية ببساطة هي أنّه ليس المؤشّر نفسه.

6.2. ما الذي يحدث فعلاً

كائن COM في STA يجب أن يعالج الاستدعاء على مؤشّر STA المالك له.
لذا حين يستدعيه مؤشّر آخر، يُحوِّل COM الاستدعاء إلى مؤشّر STA ذاك.

لكن إذا كان مؤشّر STA لا يعالج الرسائل، لا يمكن قبول الاستدعاء المُحوَّل. يبقى المُستدعِي ينتظر، ويبدو البرنامج وكأنّه مُعلَّق.

6.3. شيفرة وهمية لنمط الفشل النموذجي

var ready = new AutoResetEvent(false);
var done = new AutoResetEvent(false);

object comObj = null;
var staThread = new Thread(() =>
{
    // Initialize as STA
    CoInitializeEx(IntPtr.Zero, COINIT_APARTMENTTHREADED);

    comObj = new SomeStaComObject();
    ready.Set();

    // Waiting without a message loop -> fatal
    done.WaitOne();
});

staThread.SetApartmentState(ApartmentState.STA);
staThread.Start();

ready.WaitOne();

// Another thread (STA or MTA) calls into the object
// COM transfers the call back to the STA thread
// but the STA thread is not pumping messages
CallComObject(comObj);

sequenceDiagram
    participant Main as Main thread
    participant STA as STA thread
    participant COM as COM runtime

    Main->>STA: Start thread
    STA->>STA: CoInitializeEx (STA)
    STA->>STA: Create COM object
    STA->>Main: ready.Set()
    STA->>STA: Wait on done.WaitOne()
    Note over STA: No message loop
stuck here

    Main->>COM: CallComObject()
    COM->>STA: Try to transfer the call
    Note over COM: Transfer through message / marshaling path
    Note over STA: Cannot process it while blocked
    Note over Main: Caller keeps waiting
    Note over Main,STA: Both sides end up waiting -> hang

والافتراضات المهمّة وراء STA هي ما يلي:

• يعمل كائن COM على مؤشّر STA الذي أنشأه
• يُشغّل ذلك المؤشّر الرسائل حتى تتمكّن الاستدعاءات المُحوَّلة من الوصول

لذا إذا أنشأتَ مؤشّر STA لا يُشغّل الرسائل، فإنّه لا يستطيع تلقّي تلك الاستدعاءات المُحوَّلة. ولهذا قد ينتظر المُستدعِي إلى ما لا نهاية.

أمّا مؤشّرات ترابط واجهة المستخدم، فهي تُشغّل الرسائل أصلاً من أجل معالجة النوافذ. ومن ثَمّ، فإنّها تُلبّي متطلّبات STA الجوهرية دون أن تضطرّ إلى إضافة شيء إضافيّ.

6.4. النقاط الجوهرية للتجنّب

• إذا كان من الممكن استدعاء كائن STA من مؤشّرات أخرى، فيجب أن يُشغّل مؤشّر STA حلقة رسائل
• إن أمكن، أنشئ الكائن واستخدمه على مؤشّر واجهة المستخدم نفسه، لأنّه يمتلك حلقة رسائل أصلاً
• إن لم تكن تحتاج فعلاً إلى STA، ابدأ بـ MTA من البداية

6.5. ماذا يعني فعلاً «تشغيل حلقة الرسائل»؟

إنّها حلقة رسائل Win32 المعتادة:

while (GetMessage(out var msg, IntPtr.Zero, 0, 0))
{
    TranslateMessage(ref msg);
    DispatchMessage(ref msg);
}

في STA، تَصِل الاستدعاءات المُحوَّلة عبر آليّة الرسائل والإرسال (dispatch).
وهذه الحلقة تحديداً هي ما يستقبل تلك الاستدعاءات ويتيح لها أن تعمل.

6.6. اتّجاه أكثر سلامة (تقريباً)

إن كنت تريد فعلاً مؤشّر ترابط STA خلفي يستضيف COM، فالشكل أقرب إلى ما يلي:

var ready = new AutoResetEvent(false);
object comObj = null;

var staThread = new Thread(() =>
{
    CoInitializeEx(IntPtr.Zero, COINIT_APARTMENTTHREADED);

    comObj = new SomeStaComObject();
    ready.Set();

    // Keep pumping messages while the STA thread is alive
    Application.Run();

    CoUninitialize();
});

staThread.SetApartmentState(ApartmentState.STA);
staThread.Start();

ready.WaitOne();
CallComObject(comObj);

ونعم، نسيان CoInitializeEx / CoUninitialize طريقة عاديّة جدّاً لخلق وقت سيّئ.

6.7. نمط تعليق آخر: استدعاء عكسي أثناء استدعاء متزامن

مشكلات STA لا تقتصر على الاستدعاءات الذاهبة. في بعض الأحيان، يستدعي خادم COM العميل عكسيّاً أثناء استدعاء متزامن، وهذا يخلق نمط تعطّل (deadlock) بسهولة كبيرة.

sequenceDiagram
    participant UI as UI thread (STA)
    participant Server as COM server

    UI->>Server: DoWork() (synchronous call)
    Note over UI: Waiting for DoWork to return
not processing messages
    Server->>UI: ProgressCallback()
    Note over UI: Cannot receive callback while blocked
    Note over Server: Waiting for callback to finish
    Note over UI,Server: Each side waits for the other -> deadlock

سبب وقوع التعطّل بهذه السهولة:

1. يُجري مؤشّر واجهة المستخدم استدعاءً متزامناً لـ DoWork()
2. ينتظر مؤشّر واجهة المستخدم العودة ولا يُشغّل الرسائل
3. يُرسل الخادم ProgressCallback() عودةً إلى مؤشّر واجهة المستخدم
4. لا يستطيع مؤشّر واجهة المستخدم قبول ذلك الاستدعاء العكسي وهو محجوز
5. ينتظر الخادم اكتمال الاستدعاء العكسي
6. ينتهي الطرفان إلى الانتظار إلى الأبد

ليس لهذا علاقة بزمن المعالجة الإجمالي.
المشكلة الحقيقية هي: «وصول استدعاء عكسي أثناء استدعاء متزامن.»

ثمّة آليّات في COM يمكنها في بعض الحالات تشغيل الرسائل أو إعادة الدخول، فيتعلّق السلوك الدقيق بالمكوّن وبنمط الاستدعاء. ومع ذلك، يبقى هذا نمطاً يُستحسن تجنّبه عموماً بدلاً من الاعتماد عليه.

7. إرشادات عملية تقريبية

• تورّط واجهة مستخدم → STA
• معالجة خلفية متوازية كثيفة → MTA
• لا يَفضُل أيٌّ منهما → اتّبع متطلّب خادم COM أو المكتبة الموجودة

8. الخلاصة

ما هما STA / MTA:

• STA / MTA هما نموذجَا مؤشّرات ترابط من أجل COM، وليسا مفهومَين عامَّين لمؤشّرات ترابط Windows
• STA يعني مؤشّر ترابط واحد = Apartment واحد، بينما MTA يعني عدّة مؤشّرات ترابط تتشارك Apartment واحداً
• حين يَعبُر استدعاءٌ بين Apartments، يُحوّله COM عبر بنية Proxy / Stub و Marshaling

افتراضات STA ومآزقه:

• حين قد تَرِد استدعاءات من مؤشّرات أخرى، يُتوقَّع من مؤشّر STA أن يُشغّل الرسائل
• الاستدعاء إلى مؤشّر STA لا يُشغّل الرسائل يُسبّب حالات تعليق بسهولة
• الاستدعاءات العكسية أثناء الاستدعاءات المتزامنة نمطٌ تعطُّليٌّ شائعٌ جدّاً

العلاقة بين مؤشّرات ترابط واجهة المستخدم و STA:

• مؤشّرات ترابط واجهة المستخدم تمتلك أصلاً ألفة لمؤشّر ترابط واحد وحلقة رسائل
• ولهذا تُلبّي طبيعيّاً افتراضات STA وتنسجم جيّداً مع COM ذي الطابع STA

تنبيه على مستوى التصميم:

• استدعاءات عبور Apartments تنطوي على تكلفة Marshaling حقيقية
• إذا كان معدّل الاستدعاء مرتفعاً، يصبح تصميم Apartment موضوعاً يتعلّق بالأداء أيضاً

9. مراجع

• COM Apartments
• CoInitializeEx

تنزيل النسخة بصيغة Word من هذا المقال