تحليل الخيط الثابت: فكرة جيدة؟

Question

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

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

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

لذلك على السطح ، يبدو أن هذا مجرد إضافة منخفضة المكاسب الضخمة إلى المصدر ودورة البناء. أسئلتي هي:

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

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

Answer 1

هذه الإجابة تركز أكثر على الجانب النظري لسؤالك.

في الأساس ، تقوم بتأكيد: "هذه الأساليب تعمل فقط تحت خيوط معينة". هذا التأكيد لا يختلف حقًا عن أي تأكيد آخر قد تقوم به ("الطريقة تقبل فقط الأعداد الصحيحة أقل من 17 للمعلمة X"). القضايا

• من أين تأتي هذه التأكيدات؟
• هل يمكن للتحليلات الثابتة التحقق منها؟
• من أين تحصل على مثل هذا المحلل الثابت؟

في الغالب ، يجب أن تأتي هذه التأكيدات من مصممي البرامج ، لأنهم الأشخاص الوحيدون الذين يعرفون النوايا. المصطلح التقليدي لهذا هو "التصميم حسب العقد" ، على الرغم من أن معظم مخططات DBC هي فقط فوق تيار حالة البرنامج (C's يجزم الماكرو) وينبغي أن يكونوا حقًا على الحالات السابقة والمستقبلية للبرامج ("التأكيدات الزمنية") ، هـ. ، ز. ، "سيقوم هذا الروتين بتخصيص كتلة من التخزين ، وفي النهاية سوف يعرض بعض الكود تخصيصه". يمكن للمرء أن يبني الأدوات التي تحاول تحديد ماهية التأكيدات (على سبيل المثال ، عمل إنجلر التأكيد التعريفي ؛ قام آخرون بعمل في هذا المجال). هذا مفيد ، لكن الإيجابيات الخاطئة هي مشكلة. كمسألة عملية ، لا يبدو أن مطالبة المصممين بترميز مثل هذه التأكيدات مرهقة بشكل خاص ، وهي وثائق طويلة الأجل جيدة حقًا. سواء كنت ترمز مثل هذه التأكيدات مع بنية لغة "عقد" محددة ، أو مع إذا بيان ("إذا تصحيح و لا (التأكيد) ثم تفشل () ؛ ") أو إخفائها في التعليق التوضيحي هو في الحقيقة مجرد مسألة راحة. إنه لطيف عندما تسمح اللغة بترميز مثل هذه التأكيدات مباشرة.

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

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

تتمثل إحدى الطرق لجعل "أسهل" بناء مثل هذه المحللين الثابتة في تقييد الحالات التي يتعاملون معها لتضييق نطاق النطاق ، على سبيل المثال ، التحقق. كنت أتوقع أن تفعل ComphThread بالضبط ما تفعله حاليًا ، وسيكون من غير المرجح أن تصبح أقوى بكثير.

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

خلاصة القول: محللون ثابتون ومحللون ديناميكيين لديهم قوتهم.

Answer 2

لم نجرب أي أدوات تحليل ثابت ، لكننا استخدمنا SideJ لكتابة جانب بسيط يكتشف في وقت التشغيل عندما يتم استدعاء أي رمز في Java.awt أو Javax.swing خارج EDT. لقد وجدت عدة أماكن في الكود الذي كان مفقودًا SwingUtilities.invokeLater(). نركض مع هذا الجانب ممكّنًا خلال دورة ضمان الجودة لدينا ، ثم أطفئه قبل الإفراج بفترة قصيرة.

Answer 3

كما هو مطلوب ، لا يتعلق هذا على وجه التحديد بـ Java أو EDT ، لكنني رأيت نتائج جيدة مع Checkers تحليل ثابت من Coverity لـ C/C ++. لقد كان لديهم معدل إيجابي كاذب أعلى من المدققين الأقل تعقيدًا ، لكن يبدو أن مالكي التعليمات البرمجية على استعداد لتحمل ذلك ، بالنظر إلى مدى صعوبة العثور على أخطاء الخيوط من خلال الاختبار. أخشى أن التفاصيل سرية ، لكن أوراق داوسون إنجلر العامة (على سبيل المثال ، "الأخطاء كسلوك منحرف") جيدة جدًا في النهج العام "مثيلات" N »التالية من الكود الخاص بك" قبل القيام بذلك « ذ »، ؛ هذا الحالة لا. "