شرح النص على الخيوط في "C# 3.0 باختصار"

Question

أثناء القراءة C# 3.0 باختصار بواسطة جوزيف وبن ألباهاري, ، صادفت الفقرة التالية (صفحة 673 ، الفقرة الأولى في القسم بعنوان "الإشارة مع الانتظار والنبض")

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

سؤالي هو ، ما هو التفسير الصحيح ل الاخير جملة؟

• موقف مع عدد لائق/كبير من مقابض الانتظار حيث لا يتم استدعاء Waitone () في بعض الأحيان فقط أي مقبض انتظار معين.
• موقف مع عدد لائق/كبير من مقابض الانتظار حيث نادرا ما يميل أكثر من مؤشر ترابط واحد إلى حظر أي مقبض انتظار معين.
• بعض التفسيرات الأخرى.

من شأنه أن يقدر أيضًا أمثلة إضاءة لمثل هذه الحالات وربما كيف و/أو لماذا يتم التعامل معها بكفاءة أكبر من خلال الانتظار والنبض بدلاً من طرق أخرى.

شكرًا لك!

تحرير: لقد وجدت النص عبر الإنترنت هنا

Answer 1

ما يقوله هذا هو أن هناك بعض المواقف التي يوفر فيها الانتظار والنبض حلاً أبسط من مقابض الانتظار. بشكل عام ، يحدث هذا حيث:

• يقرر النادل ، بدلاً من المعرف ، متى يفصل
• تتضمن حالة الحظر أكثر من علامة بسيطة (ربما عدة متغيرات)

لا يزال بإمكانك استخدام مقابض الانتظار في هذه المواقف ، لكن الانتظار/النبض يميل إلى أن يكون أكثر بساطة. الشيء العظيم في الانتظار/النبض هو أن الانتظار يطلق القفل الأساسي أثناء الانتظار. على سبيل المثال ، في المثال التالي ، نقرأ _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
• المهام والاستمرارية

كل هذه المستويات أعلى بكثير من الانتظار/النبض ، ومن الأفضل لكتابة رمز موثوق به يمكن الحفاظ عليه (على افتراض أنهم سيحلون المهمة في متناول اليد).