يقرأ ويكتب إلى العقارات الذرية في C #؟

Question

يقرأ ويكتب إلى بعض أنواع البدائية في C # مثل bool و int هي ذرية.

(انظر القسم 5.5، "5.5 ذراع المراجع المتغيرة"، في مواصفات لغة C #.)

ولكن ماذا عن الوصول إلى هذه المتغيرات عبر الخصائص؟ هل من المعقول أن نفترض أنها ستكون أيضا آمنة ذرية وخيط؟ على سبيل المثال هو قراءة MyProperty أسفل الذرية والخيط آمنة؟:

public bool MyProperty { get { return _foo; } }

وماذا عن الخصائص المنفذة التلقائي؟

public bool MyProperty { get; }

Answer 1

تحتاج إلى التمييز بين "الذرية" و "آمنة الخيط" عن كثب. كما تقول، فإن الكتابة ذرية بالنسبة لمعظم أنواع القيمة المدمجة والمراجع.

ومع ذلك، هذا لا يعني أنهم آمنة للخيط. هذا يعني أنه إذا كانت القيم "A" و "B" مكتوبين، فلن يرى مؤشر ترابط ما بينهما. (على سبيل المثال، لن تظهر التغيير من 1 إلى 4 أبدا 5، أو 2، أو أي قيمة بخلاف 1 أو 4.) لا يعني أن موضوع واحد سيرى القيمة "B" بمجرد كتابة المتغير. لذلك، تحتاج إلى إلقاء نظرة على نموذج الذاكرة من حيث التقلبات. بدون حواجز الذاكرة، عادة ما يتم الحصول عليها من خلال قفل و / أو متقلب متقلب، قد يتأخر الكتب إلى الذاكرة الرئيسية ويمكن تقديم القراءات، على افتراض أن القيمة لم تتغير منذ القراءة الأخيرة.

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

هذا لا علاقة له بالخصائص، ومع ذلك - الخصائص هي ببساطة أساليب مع السكر النحوي من حولها. أنها لا تكفل إضافي حول الخيوط. .NET 2.0 نموذج الذاكرة هل لديك المزيد من الضمانات من نموذج ECMA، ومن الممكن أن يجعل الضمانات حول إدخال الأسلوب والخروج. يجب أن تنطبق هذه الضمانات على الممتلكات أيضا، على الرغم من أنني سأكون عصبيا حول تفسير هذه القواعد: قد يكون من الصعب للغاية التفكير في نماذج الذاكرة في بعض الأحيان.

Answer 2

أنا غير واضح قليلا فيما يتعلق بما تطلبه هنا. يبدو أنك يمكن أن تسأل 1 من 2 سؤال

1. هو قراءة _foo أثناء استدعاء myproperty الذرية؟
2. هي قيمة العودة من myproperty مجموعة ذرية؟

ل # 1 الجواب نعم. نظرا لأن الولايات C # Language SPOC (و CLI)، فإن قراءة ومتغيرات وكتابة أنواع مختلفة من الأنواع المحددة مضمونة لتكون ذرية. النوع "BOOL" هو أحد هذه الأنواع.

بالنسبة إلى # 2 أفضل مكان للمشاهدة هو القسم 12.6.6 من المواصفات CLI. إنها تنص على أن

يجب أن تضمن CLI مطابقة أن القراءة والكتابة الوصول إلى مواقع الذاكرة المحاذاة بشكل صحيح لا أكبر من حجم الكلمة الأصلية (حجم النوع الأصلي) هو الذرية

بالنظر إلى استخدام قيمة الإرجاع من MyProperty، يجب أن تكون تقرأ قيمة أو كتابة القيمة، فمن الآمن افتراض أن يتم تعيينها بشكل جذري.

Answer 3

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

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

Answer 4

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

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

Answer 5

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

Answer 6

يمكنك وضع أي شيء في العقار، على سبيل المثال

    Public Property foo() As Boolean
        Get
           goToLunch()
           barbecueRibs()
           return m_foo
        End Get
        Set(ByVal value As Boolean)
           takeANap()
           accessDatabase()
           messUpOtherVariables()
           m_foo = value
        End Set
    End Property