شرح النص على الخيوط في "C# 3.0 باختصار"
-
22-09-2019 - |
سؤال
أثناء القراءة C# 3.0 باختصار بواسطة جوزيف وبن ألباهاري, ، صادفت الفقرة التالية (صفحة 673 ، الفقرة الأولى في القسم بعنوان "الإشارة مع الانتظار والنبض")
"ال شاشة يوفر الفئة بناء إشارة أخرى عبر طريقتين ثابتتين ، انتظر و نبض. المبدأ هو أنك تكتب منطق الإشارة بنفسك باستخدام أعلام وحقول مخصصة (مغلقة في قفل البيانات) ، ثم تقديم انتظر و نبض أوامر لتخفيف غزل وحدة المعالجة المركزية. ميزة هذا النهج منخفض المستوى هو ذلك مع فقط انتظر, نبض, ، و ال قفل بيان ، يمكنك تحقيق وظائف Autoresetevent, ManualResetEvent, ، و إشارة, ، إلى جانب Waithandleطرق ثابتة انتظر و Waitany. بالإضافة إلى، انتظر و نبضيمكن أن يكون قابلاً للتطبيق في المواقف التي يتم فيها تحدي جميع مقابض الانتظار بشكل متكرر ".
سؤالي هو ، ما هو التفسير الصحيح ل الاخير جملة؟
- موقف مع عدد لائق/كبير من مقابض الانتظار حيث لا يتم استدعاء Waitone () في بعض الأحيان فقط أي مقبض انتظار معين.
- موقف مع عدد لائق/كبير من مقابض الانتظار حيث نادرا ما يميل أكثر من مؤشر ترابط واحد إلى حظر أي مقبض انتظار معين.
- بعض التفسيرات الأخرى.
من شأنه أن يقدر أيضًا أمثلة إضاءة لمثل هذه الحالات وربما كيف و/أو لماذا يتم التعامل معها بكفاءة أكبر من خلال الانتظار والنبض بدلاً من طرق أخرى.
شكرًا لك!
تحرير: لقد وجدت النص عبر الإنترنت هنا
المحلول
ما يقوله هذا هو أن هناك بعض المواقف التي يوفر فيها الانتظار والنبض حلاً أبسط من مقابض الانتظار. بشكل عام ، يحدث هذا حيث:
- يقرر النادل ، بدلاً من المعرف ، متى يفصل
- تتضمن حالة الحظر أكثر من علامة بسيطة (ربما عدة متغيرات)
لا يزال بإمكانك استخدام مقابض الانتظار في هذه المواقف ، لكن الانتظار/النبض يميل إلى أن يكون أكثر بساطة. الشيء العظيم في الانتظار/النبض هو أن الانتظار يطلق القفل الأساسي أثناء الانتظار. على سبيل المثال ، في المثال التالي ، نقرأ _x و _y ضمن سلامة القفل - ومع ذلك يتم إصدار هذا القفل أثناء الانتظار حتى يتمكن مؤشر ترابط آخر من تحديث هذه المتغيرات:
lock (_locker)
{
while (_x < 10 && _y < 20) Monitor.Wait (_locker);
}
يمكن بعد ذلك تحديث مؤشر ترابط آخر _x و _y ذرية (بحكم القفل) ثم النبض للإشارة إلى النادل:
lock (_locker)
{
_x = 20;
_y = 30;
Monitor.Pulse (_locker);
}
عيب الانتظار/النبض هو أنه من الأسهل الحصول على خطأ وخطأ (على سبيل المثال ، من خلال تحديث متغير ونسيان النبض). في المواقف التي يكون فيها برنامج مع مقابض الانتظار بسيطة بنفس القدر لبرنامج مع الانتظار/النبض ، أوصي بالذهاب مع مقابض الانتظار لهذا السبب.
من حيث استهلاك الكفاءة/الموارد (التي أعتقد أنك كانت تلمح إليها) ، عادة ما يكون الانتظار/النبض أسرع وأخف وزنا (لأنه يحتوي على تنفيذ مُدار). هذا نادرا ما يكون صفقة كبيرة في الممارسة العملية. وعلى هذه النقطة ، يتضمن Framework 4.0 إصدارات منخفضة رأس المال من ManualResetevent و Semaphore (ManualReseteventslim و Semaphoreslim).
يوفر Framework 4.0 أيضًا العديد من خيارات التزامن التي تقلل من الحاجة إلى الانتظار/النبض:
- CountDownevent
- حاجز
- plinq / data parallex
- المهام والاستمرارية
كل هذه المستويات أعلى بكثير من الانتظار/النبض ، ومن الأفضل لكتابة رمز موثوق به يمكن الحفاظ عليه (على افتراض أنهم سيحلون المهمة في متناول اليد).