متعددة القائمة على الرسائل أو تجمع مؤشرات الترابط لعمل قصير وغير مألوف؟

Question

أنا أستخدم حاليًا Retlang للحصول على multithreading المستندة إلى الرسائل في .NET ، وهي مكتبة رائعة. لم يعد لدي أقفال صريحة بعد الآن ، كل موضوع يقوم بأعماله التجارية الخاصة ، ويدير جزءه من التطبيق والتواصل مع مؤشرات الترابط الأخرى عبر الرسائل.

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

لذلك بدأت أتساءل عما إذا كان لدي خيط ينام بنسبة 99.9 ٪ من الوقت كان في الواقع اختيارًا جيدًا. يوجد تجمع مؤشرات الترابط لهذا النوع من العملية ، لكن نظرًا لعدم وجود تحكم في الخيط الذي سيتم استلام رسائلي ، يجب أن ألجأ إلى أقفال قبيحة معرضة للخطأ.

سؤالي هو: هل هي حقًا مشكلة ، من الحكمة ، أن تترك موضوعًا خاملاً ، في انتظار الغالبية العظمى من الوقت؟ إن استخدام Multithreading المشترك بعد استخدام بنية جيدة تستند إلى الرسائل يبدو وكأنه العودة في الوقت المناسب ، بالإضافة إلى أنه سيكون الجزء الوحيد من التطبيق مع الأقفال. لكنني ما زلت أتساءل "هل أفعل شيئًا خاطئًا هنا؟" مع هذا الموضوع.

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

Answer 1

أود أن أزعم في الواقع أن استخدام threadpool لخيط ينام معظم الوقت هو اختيار تصميم ضعيف -

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

Answer 2

هذا يبدو وكأنه سيناريو مثالي لاستخدام أ Task. يستخدمون تجمع الخيوط افتراضيًا أسفله ، لكن لديهم واجهة برمجة تطبيقات أكثر تطوراً.

Answer 3

لا يمكنك استخدام Retlang's PoolFiber لهذا؟ لا يدعمه موضوع مخصص مثل ThreadFiber ولكن بدلا من ذلك بواسطة .NET Threadpool. مما يعني أنه يمكنك الاستمرار في استخدام نفس دلالات Retlang التي تستخدمها خلال التطبيق الخاص بك دون الاحتفاظ بخيط خمول.

Answer 4

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

يجب أن تفعل Poolfiber ما تبحث عنه.

Answer 5

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

Answer 6

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

Answer 7

يجب أن تفكر في استخدام F#. إنه لأمر رائع لبرمجة العوامل التي تنطلق من الناحية المنطقية دون حرق الخيوط (يمكن أن يقفز وكلاء على سبيل المثال عن Threadpool ، ولكن لا يزال يستجيب للرسائل بطريقة تسلسل ، ورسالة قادمة إلى صندوق البريد الخاص بهم تستيقظهم وجدولة عمل Threadpool).

http://blogs.msdn.com/b/dsyme/archive/2010/02/15/async-paralled-sigign-patterns-in-f-part-3-agents.aspx