Ce n'est thread-safe signifie?

Eric Lippert a un joli blog post intitulé Quelle est cette chose que vous appelez un "thread-safe"? sur la définition de la sécurité des threads, comme l'a constaté de Wikipédia.

3 choses importantes extraites à partir de ces liens :

“Un morceau de code est thread-safe s'il fonctionne correctement pendant
exécution simultanée par plusieurs threads.”

“En particulier, il doit satisfaire les besoins de plusieurs threads
accéder aux mêmes données partagées, ...”

“...et la nécessité du partage des morceau de données accessibles par un seul
le fil à un moment donné.”

Vaut vraiment le lire!

Wikipédia a un article sur la Sécurité des Threads.

Ce définitions page (vous devez passer une annonce - désolé) le définit ainsi:

Dans la programmation informatique, thread-safe décrit un programme ou sous-programme peut être appelé à partir de multiples de programmation des threads sans interaction indésirable entre les threads.

Un thread est un chemin d'exécution d'un programme. Un seul thread programme n'ont qu'un seul thread et donc ce problème ne se pose pas. Pratiquement tous les programmes graphiques ont plusieurs chemins d'exécution et, par conséquent, des filets il y a au moins deux, l'un pour le traitement de l'affichage de l'interface graphique et de remise de la saisie de l'utilisateur, et au moins un autre pour effectuer les opérations du programme.

Ceci est fait de sorte que l'INTERFACE utilisateur est toujours sensible alors que le programme de travail en transférant un long processus en cours d'exécution à tout non-INTERFACE de threads. Ces fils peuvent être créés une fois que les et n'existent que pour la durée de vie du programme, ou tout simplement obtenir créés en cas de besoin et détruits quand ils ont fini.

Que ces threads doivent souvent effectuer des actions communes - i/o disque, de la sortie des résultats sur l'écran etc. - ces parties du code devra être écrit de telle façon qu'elles peuvent être appelées à partir de plusieurs threads, souvent en même temps. Cela implique des choses comme:

• Travailler sur des copies de données
• L'ajout de serrures autour de la critique du code

Un module est thread-safe, si elle garantit de pouvoir conserver ses invariants dans le visage de multi-thread et agrément d'utilisation.

Ici, un module peut être une structure de données, de classe, d'objet, de méthode, de procédure ou de fonction. Fondamentalement, l'étendue morceau de code et de données connexes.

La garantie peut éventuellement être limitée à certains environnements spécifiques de l'architecture du PROCESSEUR, mais il doit détenir pour les environnements. Si il n'est pas explicite à la délimitation des milieux, alors qu'il est généralement pris à penser qu'il vaut pour tous les environnements que le code peut être compilé et exécuté.

Thread-dangereux modules peut fonctionner correctement sous multi-thread et l'utilisation simultanée, mais c'est souvent plus bas à la chance et le hasard, qu'une conception soignée. Même si certains module n'a pas de pause pour vous, il peut se briser lors d'un déplacement à d'autres environnements.

Multi-threading, des bugs sont souvent difficiles à déboguer. Certaines d'entre elles ne produisent de temps en temps, tandis que d'autres manifestent de façon agressive - ce trop, peut-être spécifiques à un environnement. Ils peuvent se manifester comme subtilement de mauvais résultats, ou de blocages. Ils peuvent gâcher des données-structures de manière imprévisible, et causer d'autres apparemment impossible de bugs apparaissent dans d'autres régions éloignées du code. Il peut être très spécifiques à l'application, de sorte qu'il est difficile de donner une description générale.

Dans l'exemple du monde réel pour le profane est

Supposons que vous avez un compte en banque avec l'internet et le mobile banking et votre compte seulement 10$.
Vous avez effectué le transfert de l'équilibre à un autre compte à l'aide de services bancaires mobiles, et en attendant, vous avez fait du shopping en ligne en utilisant le même compte en banque.
Si ce compte en banque n'est pas thread-safe, la banque vous permet d'effectuer les deux opérations en même temps et ensuite, la banque fait faillite.

Thread-safe signifie que l'état d'un objet ne change pas si simultanément plusieurs threads tentent d'accéder à l'objet.

Vous êtes clairement dans un WinForms de l'environnement. WinForms contrôles de l'exposition l'affinité de thread, ce qui signifie que le thread dans lequel ils sont créés est le seul fil qui peut être utilisé pour accéder et mettre à jour. C'est pourquoi vous trouverez des exemples sur MSDN et d'ailleurs de démontrer comment marshall à l'appel en arrière sur le thread principal.

Normal WinForms pratique est d'avoir un seul thread qui est dédié à tous de votre INTERFACE de travail.

Pour comprendre la sécurité des threads, lire ci-dessous les sections:

4.3.1. Exemple: Le Traqueur De Véhicule À L'Aide De Délégation

Comme un plus substantielle de l'exemple de la délégation, nous allons construire une version du traqueur de véhicule que les délégués à un thread-safe classe. Nous stockons les emplacements sur une Carte, nous commençons donc avec un "thread-safe" de la Carte de mise en œuvre, ConcurrentHashMap. Nous avons également stocker l'emplacement à l'aide d'un immuable classe Point au lieu de MutablePoint, dans le Listing 4.6.

Listing 4.6. Immuable classe Point utilisé par DelegatingVehicleTracker.

 class Point{
  public final int x, y;

  public Point() {
        this.x=0; this.y=0;
    }

  public Point(int x, int y) {
        this.x = x;
        this.y = y;
    }

}

Point est thread-safe, car il est immuable. Immuable valeurs peuvent être librement partagés et publiés, de sorte que nous n'avons plus besoin de copier les lieux lors de leur retour.

DelegatingVehicleTracker dans le Listing 4.7 ne pas utiliser explicite de la synchronisation; tous l'accès à l'état est géré par ConcurrentHashMap, et toutes les clés et les valeurs de la Carte sont immuables.

Listing 4.7. Déléguer la Sécurité des Threads à un ConcurrentHashMap.

  public class DelegatingVehicleTracker {

  private final ConcurrentMap<String, Point> locations;
    private final Map<String, Point> unmodifiableMap;

  public DelegatingVehicleTracker(Map<String, Point> points) {
        this.locations = new ConcurrentHashMap<String, Point>(points);
        this.unmodifiableMap = Collections.unmodifiableMap(locations);
    }

  public Map<String, Point> getLocations(){
        return this.unmodifiableMap; //User cannot update point(x,y) as Point is immutable
    }

  public Point getLocation(String id) {
        return locations.get(id);
    }

  public void setLocation(String id, int x, int y) {
        if(locations.replace(id, new Point(x, y)) == null) {
             throw new IllegalArgumentException("invalid vehicle name: " + id);
        }
    }

}

Si l'on avait utilisé l'original MutablePoint classe à la place du Point, nous briserions encapsulation en laissant getLocations publier une référence à mutable état qui n'est pas thread-safe. Notez que nous avons changé le comportement des traqueur de véhicule de classe légèrement, tandis que le moniteur version retournée un aperçu de l'emplacement, la délégation de la version renvoie un inmodifiable, mais “vivre” la vue de l'emplacement des véhicules. Cela signifie que si Un thread appelle getLocations et le fil B plus tard modifie la localisation de certains points, ces modifications sont reflétées dans la Carte retournée à filetage A.

4.3.2. Indépendant Des Variables D'État

On peut également déléguer la sécurité des threads de plus d'un état sous-jacent variable aussi longtemps que ceux qui sous-tendent les variables d'état sont indépendantes, ce qui signifie que le composite de classe n'impose aucune invariants impliquant de multiples variables d'état.

VisualComponent dans le Listing 4.9 est un composant graphique qui permet aux clients d'enregistrer des écouteurs pour la souris et la frappe des événements. Il maintient une liste des auditeurs de chaque type, de sorte que lorsqu'un événement se produit, les écouteurs appropriés peuvent être invoquées. Mais il n'y a pas de relation entre l'ensemble des écouteurs de souris et touche les auditeurs; les deux sont indépendants, et donc VisualComponent peut déléguer son thread obligations en matière de sécurité à deux sous-jacent thread-safe listes.

Listing 4.9. Déléguer la Sécurité des Threads à de Multiples sous-jacents Variables d'État.

public class VisualComponent {
    private final List<KeyListener> keyListeners 
                                        = new CopyOnWriteArrayList<KeyListener>();
    private final List<MouseListener> mouseListeners 
                                        = new CopyOnWriteArrayList<MouseListener>();

  public void addKeyListener(KeyListener listener) {
        keyListeners.add(listener);
    }

  public void addMouseListener(MouseListener listener) {
        mouseListeners.add(listener);
    }

  public void removeKeyListener(KeyListener listener) {
        keyListeners.remove(listener);
    }

  public void removeMouseListener(MouseListener listener) {
        mouseListeners.remove(listener);
    }

}

VisualComponent utilise un CopyOnWriteArrayList pour stocker chaque auditeur de la liste; c'est un "thread-safe" de la Liste de mise en œuvre particulièrement adapté pour la gestion de l'auditeur listes (voir Section 5.2.3). Chaque Liste est thread-safe, et parce qu'il n'y a pas de contraintes de couplage de l'état de l'un à l'état de l'autre, VisualComponent peut déléguer son thread responsabilités en matière de sécurité de la sous - mouseListeners et keyListeners objets.

4.3.3. Lorsque La Délégation Échoue

Plus composite classes ne sont pas aussi simple que VisualComponent: ils ont des invariants qui se rapportent à des variables d'état. NumberRange dans le Listing 4.10 utilise deux AtomicIntegers à gérer son état, mais impose une contrainte supplémentaire—que le premier numéro, être inférieure ou égale à la seconde.

Listing 4.10. Plage de numéro de Classe qui ne Protègent Pas Suffisamment Ses Invariants. Ne pas le faire.

public class NumberRange {

  //INVARIANT: lower <= upper
    private final AtomicInteger lower = new AtomicInteger(0);
    private final AtomicInteger upper = new AtomicInteger(0);

  public void setLower(int i) {
        //Warning - unsafe check-then-act
        if(i > upper.get()) {
            throw new IllegalArgumentException(
                    "Can't set lower to " + i + " > upper ");
        }
        lower.set(i);
    }

  public void setUpper(int i) {
        //Warning - unsafe check-then-act
        if(i < lower.get()) {
            throw new IllegalArgumentException(
                    "Can't set upper to " + i + " < lower ");
        }
        upper.set(i);
    }

  public boolean isInRange(int i){
        return (i >= lower.get() && i <= upper.get());
    }

}

NumberRange est pas thread-safe; il ne permet pas de conserver l'invariant qui limite inférieure et supérieure. Le setLower et setUpper méthodes d'essayer de respecter cet invariant, mais le faire mal. Les deux setLower et setUpper sont check-puis-loi sur les séquences, mais ils n'utilisent pas suffisamment de verrouillage afin de les rendre atomique. Si le numéro de plage est titulaire d' (0, 10), et un thread appelle setLower(5) tandis qu'un autre thread appelle setUpper(4), avec quelques malchanceux calendrier tous les deux vont passer les contrôles dans les organismes de normalisation et les deux modifications seront appliquées. Le résultat est que la gamme détient désormais (5, 4)—un état non valide. Donc tandis que le sous-jacent AtomicIntegers sont thread-safe, le composite de classe n'est pas. Parce que l'état sous-jacent variables lower et upper ne sont pas indépendants, NumberRange ne peut pas simplement déléguer la sécurité des threads à son thread-safe variables d'état.

NumberRange pourrait être thread-safe en utilisant le verrouillage de maintenir ses invariants, telles que la protection supérieure et inférieure de la commune de verrouillage. Il doit également éviter de publier inférieure et supérieure pour empêcher les clients d'une subversion de ses invariants.

Si une classe a composé des actions, comme NumberRange ne, délégation à lui seul n'est pas une approche appropriée pour la sécurité des threads. Dans ces cas, la classe doit fournir ses propres verrouillage pour s'assurer que le composé d'actions sont atomiques, à moins que l'ensemble de l'action composés peuvent également être déléguées à l'état sous-jacent variables.

Si une classe est composée de plusieurs indépendants thread-safe variables d'état et n'a aucune des opérations qui ont de tout état non valide transitions, alors il peut déléguer fil de sécurité à l'état sous-jacent variables.