Ce n'est thread-safe signifie?

Question

Récemment, j'ai essayé d'Accéder à une zone de texte à partir d'un thread (autre que le thread d'INTERFACE utilisateur) et une exception a été levée, elle a dit quelque chose à propos du "code qui n'est pas thread-safe" et donc j'ai fini par écrire un délégué (échantillon à partir de MSDN aidé) et de l'appeler à la place.

Mais même si je n'ai pas tout à fait comprendre pourquoi tous les code supplémentaire est nécessaire

Mise à jour: Vais-je courir dans des problèmes graves si je vérifie

Les contrôles.CheckForIllegalCrossThread..bla =true

Answer 1

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

Certainement intéressant à lire!

Answer 2

En termes plus simples thread-safe signifie qu'il est sûr d'être consulté à partir de plusieurs threads. Lorsque vous utilisez plusieurs threads dans un programme, et ils sont chaque tentative d'accès à une structure commune de données ou de l'emplacement dans la mémoire de plusieurs mauvaises choses peuvent se produire. Donc, vous ajoutez un peu de code supplémentaire pour empêcher ces mauvaises choses. Par exemple, si deux personnes ont écrit le même document en même temps, la deuxième personne pour en sauver va remplacer le travail de la première personne. Pour le rendre thread-safe ensuite, vous avez à la force de la personne de 1 à attendre pour la personne 2 pour terminer leur tâche avant de permettre à la personne 1 pour modifier le document.

Answer 3

Wikipedia a un article sur la Sécurité des Threads.

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

En 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 chemin d'exécution et, partant, fils - l'un pour le traitement de l'affichage de l'interface graphique et de remise de la saisie de l'utilisateur, d'autres pour effectuer les opérations du programme. C'est ainsi que l'INTERFACE utilisateur est toujours sensible alors que le programme de travail.

Answer 4

Vous pouvez obtenir plus d'explications dans le livre "Java Simultanéité dans la Pratique":

Une classe est thread‐safe s'il se comporte correctement lors de l'accès à partir de plusieurs threads, indépendamment de la planification ou de l'entrelacement de l'exécution de ces threads par l'environnement d'exécution, et l'absence de synchronisation supplémentaires ou d'autres de la coordination de la partie du code appelant.

Answer 5

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 ou de procédure ou une 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é.

Fil-dangereux modules peuvent 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.

Le 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.