Sind C# automatisch implementierten statischen Eigenschaften, die thread-sicher?

Ich würde gerne wissen, ob C# automatisch implementierte Eigenschaften, wie public static T Prop { get; set; } sind thread-safe ist oder nicht. Danke!

  • Man müsste definieren, was genau meinen Sie mit "thread-safe" in diesem besonderen Fall, ersten.
  • Durch thread-sichere ich meine, wenn ich Schreibe den Wert in einem thread und einem anderen thread versucht, es zu Lesen, könnte der zweite thread erhalten einen falschen Wert.
InformationsquelleAutor Miguel Angelo | 2010-01-15
  1. 15

    Erscheint es nicht. Dies ist die Dekompilierung mit Reflektor:

    private static string Test
{
    [CompilerGenerated]
    get
    {
        return <Test>k__BackingField;
    }
    [CompilerGenerated]
    set
    {
        <Test>k__BackingField = value;
    }
}
    • Das ist irgendwie falsch. .NET-Speicher-Modell garantiert, dass Sie schreibt, werden Atom-und sichtbar für alle threads, zumindest die regelmäßigen .NET Framework, und wenn Sie sind nicht virtuell, Sie werden immer eingebettet. Beide sind Implementierungsdetails der .NET desktop-framework und sind nicht garantiert durch die Skillung, obwohl.
    • äh ich meine die Dekompilierung ist richtig, aber die Art und Weise Sie umgesetzt werden-garantiert Atomarität, zumindest für ganze zahlen und Referenz-Typen (mit der offensichtlichen Einschränkung, dass die Atomarität != thread-Sicherheit). Für longs/doubles/Strukturen/etc. du bist auf, du bist auf eigene Faust, though.
    • Die Spezifikation garantiert, dass Dinge wie Int32, float und Verweise sind atomic. Es macht nicht viele Garantien über Gewinde Sichtbarkeit / register Zwischenspeichern etc.
    • ist das k__BackingField, dass Sie dekompiliert flüchtigen?
    • Ähm... ist das nicht irgendwie die definition von atomic?: en.wikipedia.org/wiki/Atomicity_%28programming%29 ... zumindest auf x86/x64 einen Zaun nach dem schreiben sollten ausreichen, um zu garantieren, dass "wenn ein thread sieht es, alle threads, die es sehen".
    • Wie ich es verstehe in diesem Zusammenhang "atomic" bedeutet, dass es nicht gesehen werden können mid-update. Zum Beispiel double ist nicht garantiert atomar; wenn Sie ein double-Feld aus {x} von {y}, einem anderen thread sehen konnte, nach nur die erste Hälfte wurde aktualisiert - es könnte sich auch ein verschiedene Anzahl ({z}), der nie existierte als eine "echte" Wert des Feldes (riesige Korruption Problem).
    • Ich denke, atomic ist definiert als "in einem, unsplitable Schritt"... so dass nichts passiert gleichzeitig mit, dass der Unterricht... aber es bedeutet nicht, dass es synchronisiert Prozessor-caches... wenn das automatische Rendern " hätte keine Bedeutung
    • Ich bin falsch, es ist nicht, dass es keine Parallelität, aber es kann nicht gebrochen werden, sobald es begonnen hat.
    • Nein, es ist nicht flüchtig. Ich entschuldige mich für nicht früher reagiert, anstrengenden Tag und alle ...
    • volatile = der compiler nicht umsortieren.

    InformationsquelleAutor quentin-starin
  2. 51

    Abschnitt 10.7.4 ausgeliefert wird der C# - Spezifikation besagt:

    Wenn eine Eigenschaft ist definiert als
    automatisch implementierte Eigenschaft, ein
    versteckte Feld sichern automatisch
    zur Immobilie, und die
    Accessoren implementiert sind, um zu Lesen
    und schreiben, das Feld sichern. Die
    Folgendes Beispiel:

    public class Point {
  public int X { get; set; } //automatically implemented
  public int Y { get; set; } //automatically implemented
}

    ist äquivalent zu der folgenden Erklärung:

    public class Point {
  private int x;
  private int y;
  public int X { get { return x; } set { x = value; } }
  public int Y { get { return y; } set { y = value; } }
}

    Dass das, was wir Versprechen, und das ist, was Sie bekommen. Der Punkt der automatischen Eigenschaften zu tun, die die meisten grundlegenden, einfache, billige Sache, wenn Sie wollen, um etwas schicker mag, dann sollten Sie schreiben, eine "echte" Eigenschaft.

    • Von Ihnen positiv bewertet werden, die Sie für die Referenzierung der eigentlichen C# - Spezifikation.
    • Gut, es wird Eric Lippert beantworten... 😀
    InformationsquelleAutor Eric Lippert
  3. 6

    Nicht. Sie müssen wickeln Sie Sie in thread-locking-Mechanismen.

    object _lock = new object();
public static Main(string[] args)
{
    lock(_lock)
    {
         Prop = new T();
    }


    T val = null;
    lock(_lock)
    {
         val = Prop;
    }
}
    • Was ist Eig.? Was ist T?
    • Prop und T sind von der Frage.
    InformationsquelleAutor Amy
  4. 4

    Glaube ich nicht so. Ich glaube, Sie sind nur syntatic Zucker:

    private static T _prop;
public static T Prop
{
    get { return _prop; }
    set { _prop = value; }
}
    InformationsquelleAutor Nick
  5. 4

    Es ist keine Synchronisation mit einem automatischen Eigenschaften, einschließlich der statischen Eigenschaften.

    Wenn Sie voller thread-Sicherheit, Sie werden wollen, verwenden Sie Ihre eigenen Eigenschaften mit einem Feld sichern, und Griff die Synchronisation selbst.

    InformationsquelleAutor Reed Copsey
  6. 4

    Für die Vollständigkeit, Feld-wie bei den Ereignissen tun haben thread-Sicherheit gebaut, aber Sie sind allein in diesem. Automatisch implementierte Eigenschaften nicht haben solche Funktionen. Sie können jedoch etwas tun:

    public static double SomeProp
{   //### NOT RECOMMENDED ###
    [MethodImpl(MethodImplOptions.Synchronized)] get;
    [MethodImpl(MethodImplOptions.Synchronized)] set;
}

    Das problem mit diesem ist, dass es blockiert den Type, das ist ein schlechte Sache. Ich würde die Umsetzung eigener Synchronisation für diese persönlich.

    • "bad" aus Gründen der "marshal-by-bleed", wo der Typ lock blutet in den anderen isoliert, appdomains in einem Prozess...
    • Es ist schlimm genug, nur mit einer app-domain Wahrheit gesagt werden.
    InformationsquelleAutor Marc Gravell
  7. 2

    Nein, Sie ist nicht threadsicher. Statische Eigenschaften genauso anfällig wie statische Felder sind, um Parallelitätsprobleme.

    InformationsquelleAutor G-Wiz
Schreibe einen Kommentar