هو مقطع حرج دائما أسرع ؟

Question

كنت التصحيح تطبيق متعددة الخيوط وجدت الهيكل الداخلي CRITICAL_SECTION.وجدت بيانات الأعضاء LockSemaphore من CRITICAL_SECTION مثيرة للاهتمام.

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

الآن أنا أتساءل أمر بالغ الأهمية القسم دائما أسرع ؟ الحدث هو كائن kernel و كل مقطع حرج الكائن المقترنة مع كائن الحدث ثم كيف Critical Section يمكن أن يكون أسرع بالمقارنة مع غيرها من لب الأشياء مثل مزامنة?أيضا, كيف حدث داخلي كائن في الواقع يؤثر على أداء الحرجة القسم ؟

هنا هو هيكل CRITICAL_SECTION:

struct RTL_CRITICAL_SECTION
{
    PRTL_CRITICAL_SECTION_DEBUG DebugInfo;
    LONG LockCount;
    LONG RecursionCount;
    HANDLE OwningThread;
    HANDLE LockSemaphore;
    ULONG_PTR SpinCount;
};

Answer 1

وعندما يقولون أن مقطع حرج هو "سريع"، إلا أنها تعني "انها رخيصة للحصول على واحدة عندما لا يتم تأمينه بالفعل موضوع آخر".

[لاحظ أنه إذا كان <م> هو تخوض بالفعل موضوع آخر، ثم لا يهم ما يقرب من ذلك بكثير مدى سرعة هو عليه.]

والسبب انها سريعة غير أنه، قبل الخوض في النواة، ويستخدم ما يعادل InterlockedIncrement على واحدة من تلك الحقل LONG (ربما على مجال LockCount)، وإذا ما نجح بعد ذلك أنها تعتبر قفل المكتسبة دون أن ذهب في النواة.

وأعتقد أن تنفيذ API InterlockedIncrement في وضع المستخدم بأنه "LOCK INC" شفرة تشغيل ... وبعبارة أخرى يمكنك الحصول على مقطع حرج بالتزكية دون أن تفعل أي انتقال حلقة في نواة على الإطلاق.

Answer 2

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

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

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

إذا الحرجة قسم الأداء الحاسمة ، ثم يمكنك أن تنظر في ما يلي.

1. مجموعة بعناية تدور قفل الاعتماد الخاصة بك 'ساخنة' المقاطع الحرجة.إذا كان الأداء هو الهدف الأسمى ، ثم العمل هنا هو يستحق ذلك.تذكر, في حين تدور قفل لا تجنب وضع المستخدم إلى نواة انتقالية ، فإنه يستهلك وقت وحدة المعالجة المركزية في معدل غاضبة بينما الغزل شيء آخر يحصل لاستخدام هذا وقت وحدة المعالجة المركزية.إذا قفل لمدة طويلة بما فيه الكفاية ، ثم الغزل الموضوع الفعلية كتلة ، وتحرير ذلك وحدة المعالجة المركزية للقيام بأعمال أخرى.
2. إذا كان لديك قارئ/الكاتب نمط ثم النظر في استخدام نحيل القارئ/الكاتب (SRW) أقفال.الجانب السلبي هنا هو أنها متوفرة فقط على ويندوز فيستا و ويندوز سيرفر 2008 و في وقت لاحق المنتجات.
3. كنت قد تكون قادرة على استخدام حالة المتغيرات مع مقطع حرج لتقليل الاقتراع و الخلاف, الاستيقاظ المواضيع عند الحاجة فقط.مرة أخرى, هذه هي معتمدة على Vista و Windows Server 2008 وما بعدها من المنتجات.
4. النظر في استخدام متشابكة منفردة القوائم المرتبطة (SLIST)- هذه هي فعالة و 'قفل الحرة'.حتى أفضل ، وهي معتمدة على XP و Windows Server 2003 وما بعدها من المنتجات.
5. فحص التعليمات البرمجية الخاصة بك - كنت قد تكون قادرة على تفريق 'ساخنة' القفل عن طريق إعادة بيع ديون بعض التعليمات البرمجية باستخدام متشابكة العملية ، أو SLIST التزامن والاتصالات.

في ملخص - ضبط السيناريوهات التي قد قفل الخلاف يمكن أن يكون تحديا (ولكن مثيرة للاهتمام!) العمل.التركيز على قياس التطبيقات الخاصة بك الأداء والفهم حيث الساخن الخاص بك المسارات.على xperf أدوات في أداء ويندوز مجموعة أدوات هو صديقك هنا :) نحن صدر للتو نسخة 4.5 في Microsoft Windows SDK لنظام التشغيل Windows 7 .NET Framework 3.5 SP1 (ISO هنا, ويب المثبت هنا).يمكنك أن تجد منتدى xperf أدوات هنا.V4.5 بالكامل يدعم Win7, Vista, Windows Server 2008 - جميع الإصدارات.

Answer 3

وCriticalSections أسرع، ولكن InterlockedIncrement / InterlockedDecrement ما هو أكثر. نرى هذا التطبيق استخدام عينة LightweightLock نسخة الكاملة .

Answer 4

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

وتحرير: ذهبت وجدت بعض التعليقات في قانون بلدي: يستخدم على ما يبدو كومة مدير MS العد تدور من 4000 (بزيادة عدد صحيح، وليس مللي ثانية)

Answer 5

وإليك طريقة انظر في ذلك:

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

عندما يكون هناك خلاف ، CriticalSection هو قليلا أكثر تكلفة من استخدام مزامنة مباشرة (بسبب عمل إضافي للكشف عن spinlock الدولة).

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

Answer 6

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