C# et le fil de sécurité d'un bool

Je suis très confus au sujet de ce sujet - si la lecture de/basculement d'une valeur booléenne est thread-safe.

    //case one, nothing
    private bool v1;
    public bool V1 { get { return v1; } set { v1 = value; } }

    //case two, with Interlocked on set
    private int v2;
    public int V2 { get { return v2; } set { Interlocked.Exchange(ref v2, value); } }

    //case three, with lock on set
    private object fieldLock = new object();
    private bool v3;
    public bool V3 { get { return v3; } set { lock (fieldLock) v3 = value; } }

Sont tous thread-safe?

MODIFIER

De ce que j'ai lu (cliquez sur) atomicité de bool ne la garantit pas thread-safe. Ensuite volatile type d'aide?

Aucune de ces sont thread-safe. Le thread qui appelle la lecture lira toujours un état de la valeur. Comment rassis il est dépend du processeur et de l'optimiseur. Les gammes de quelques nanosecondes à l'infini. La lecture doit se synchroniser. Ou si vous voulez utiliser ManualResetEvent/Slim.
le Détachement est toujours une opération atomique False, long (64 bits) cession par un 32 bits, le programme n'est pas atomique.
Un getter peut lire une ancienne valeur, ce qui est compréhensible. Cependant, comment pourrait-il durer à l'infini? À l'aide d'un verrou en lecture sur le correct valeur - de relire comme si elle était instable? Je ne pense pas que cela fonctionne de cette façon, je suis confus au sujet de ce que vous dites. Je pensais qu'une fois que personne n'est à l'écriture de plus, la lecture ne peut fonctionner correctement.
Il sera l'infini lorsque l'optimiseur de magasins de la sauvegarde de variable dans un processeur de s'inscrire et de ne pas le recharger à partir de la mémoire. Parce qu'il ne sait pas qu'un autre thread puisse le mettre à jour. Le x86 gigue n'est que si le booléen n'est pas déclaré volatile. Exemple ici.
Merci, c'est clair maintenant 🙂

OriginalL'auteur Patryk Gołębiowski | 2015-04-02

c#multithreading thread-safety

20

Non, tous ne sont pas thread-safe.

Cas où l'un n'est en fait pas complètement thread-safe, ou pour mieux dire - il n'est pas thread-safe. Même si les opérations avec les booléens sont atomiques, la valeur de la variable peut être stocké dans un cache, et donc, comme les processeurs multicœurs chaque cœur possède son propre cache, la valeur peut être potentiellement endommagé.

D'aller plus loin encore, le compilateur et le PROCESSEUR peut effectuer certaines optimisations internes, y compris l'instruction de la réorganisation, qui peuvent nuire à votre logique du programme.

Vous pouvez ajouter la volatile mot-clé, d'informer le compilateur que ce champ est utilisé dans un environnement multi-thread contexte. Il permettra de résoudre les problèmes avec le cache et l'instruction de réorganisation, mais ne vous donne pas vraiment "thread-safe" code (que les opérations d'écriture encore seront pas synchronisés). Aussi volatile ne peut pas être appliqué à une variable locale.

Quand on parle de multi-threading, vous devez toujours utiliser une technique de synchronisation des threads sur les ressources précieuses.

Pour plus d'informations lire cette réponse, qui a une explication plus approfondie des différentes techniques. (exemple il y a environ int, mais n'a pas vraiment d'importance, il décrit l'approche générale.)

valeur peut être potentiellement corrompu Non, la valeur ne peut pas être corrompu (comme dans "transformer illégale/valeur non définie"). Vous pourriez obtenir rassis ("vieux").
Je veux dire "corrompu" d'une manière "non pas un, qu'il devrait être ou vous vous attendez à ce qu'il soit". Certainement pas un corrompu dans le sens d'une corruption de la mémoire:)

OriginalL'auteur Yura

Un peu de retard mais devrait être utile aux autres.

Vous pouvez implémenter votre propre thread-safe booléenne de la manière suivante:

//default is false, set 1 for true.
private int _threadSafeBoolBackValue = 0;

public bool ThreadSafeBool
{
    get { return (Interlocked.CompareExchange(ref _threadSafeBoolBackValue, 1, 1) == 1); }
    set
    {
        if (value) Interlocked.CompareExchange(ref _threadSafeBoolBackValue, 1, 0);
        else Interlocked.CompareExchange(ref _threadSafeBoolBackValue, 0, 1);
    }
}

Assurez-vous d'utiliser la Propriété de partout, jamais accès int variable directement.

OriginalL'auteur lilo0

Vous devez vous connecter pour publier un commentaire.