قواعد البحث عن/تجنب البيانات المشتركة في تطبيق متعدد الخيوط

Question

مرحبا،

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

إذن ما أحب أن أعرفه:هل لديك اقتراحات للأنماط/القواعد وما إلى ذلك؟لتحديد البيانات المشتركة؟أو تقنيات للتأكد من أن التعليمات البرمجية الخاصة بك آمنة لسلسلة الرسائل.

على سبيل المثال:

• لا ينبغي للطرق الثابتة تعديل حقول الفصل.(ما لم يغلقوا الحقل.)
  
• لا ينبغي تمرير معلمات النوع المرجعي للطريقة "مباشرة".قم دائمًا بتمرير نسخة.

بالمناسبة:

تعمل شركة Microsoft Research على شطرنج.أداة للعثور على Heisenbugs وإعادة إنتاجها في البرامج المتزامنة.آمل أن يؤدي هذا وPLINQ إلى تحسين تطوير البرامج المتزامنة.

Answer 1

حيثما كان ذلك ممكنًا، اجعل أنواعك غير قابلة للتغيير في البداية.ثم ليست هناك حاجة للاستنساخ.إذا كنت بحاجة إلى "تغيير" محتويات كائن ما، فاجعل الطريقة تعيد كائنًا جديدًا بدلاً من ذلك - تمامًا مثل String.Replace الخ يفعل.

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

Answer 2

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

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