Qu'est-ce que le filetage contexte?
Un contexte du thread se référer à un fil de la mémoire personnelle? Si oui, comment la mémoire est partagée entre plusieurs threads?
Je ne suis pas à la recherche pour les exemples de code - je comprends la synchronisation sur un niveau élevé, je suis juste confus au sujet de ce terme, et qui cherchent à avoir un aperçu sur ce qui se passe réellement derrière les scènes.
La raison que je pense/crois que chaque thread a une sorte de mémoire privée était à cause de la volatilité des mots clés dans Java et .NET, et comment les différents threads peuvent avoir des valeurs différentes pour la même primitive si elle n'est pas utilisée. Que toujours implicite privé de mémoire pour moi.
Que je ne savais pas que le terme est plus général, je suppose que je me demande comment commutation de contexte fonctionne en Java et C# spécifiquement.
- Fournir un contexte où vous avez obtenu "contexte de thread" peut vous aider avec une réponse. Les Threads n'ont pas de "copie personnelle de mémoire" dans la .Net modèle de mémoire...
- Alexei est tout à fait juste; sans dire où vous avez entendu parler de ce terme ou de comment il a été utilisé, il est difficile de dire. Par exemple, dans la Tâche de base de l'Asynchronie Modèle là est un objet appelé le filetage contexte et qui a un sens très précis lorsque vous parlez APPUYEZ sur la programmation. (Parce que la continuation d'une tâche est toujours planifiée pour s'exécuter dans un thread qui a eu le même "contexte" comme le fil qui attendait la tâche).
- En particulier, êtes-vous poser des questions sur le sens de la
CurrentContextpropriété d'unThreadobjet? - Peu importe si ce que vous entendez par "contexte", je suis complètement confus au sujet de ce que vous entendez par "portée" - champ d'application est une propriété des choses qui ont des noms et n'a de sens au moment de la compilation. Le champ d'application d'un champ, disons, est la zone de texte du programme dans lequel ce champ peut être désigné par son nom non qualifié. Quel est le rapport avec les threads? Aussi, je ne comprends pas ce que tu veux dire par "une copie personnelle de la mémoire". Ce n'est pas comment la mémoire fonctionne. Espaces d'adressage virtuel sont par processus, et non pas par thread.
- Dans l'ensemble, maintenant, je ne suis même pas sûr que cette question est responsable. Pouvez-vous clarifier tout un tas de?
- Oui, permettez-moi de modifier... je vais essayer d'approfondir.
- Édité. J'espère avoir été plus clair. Je ne suis pas une question sur une propriété.
- Le changement de contexte n'est pas un langage / framework fonctionnalité.. c'est un OS de la fonctionnalité.
- Oh. Je pensais que la machine virtuelle manipuler, mais je suppose que vous avez raison. Les Threads natifs... je pense. Commençant à douter de tout 🙂
- Les Threads sont à la fois indigène et gérés .NET. Les Threads qui sont gérés par le CLR ont beaucoup de restrictions imposées par l'environnement d'exécution, qui a réellement de threads natifs n'ont pas. Par exemple, un thread géré exception d'abandon n'est jamais jeté tout un thread géré l'exécution de code natif. Par exemple, le CLR garantit qu'aucune des conditions de course dans vérifiables code corrompus du CLR, structures de données, même si elles sont corrompre vos structures de données.
Vous devez vous connecter pour publier un commentaire.
OK, maintenant nous sommes à la source de votre confusion. C'est l'un des plus troublantes que les parties à propos de la programmation moderne. Vous avez pour envelopper votre tête autour de cette contradiction:
Comment peut-il être? Parce que
processeurs faire des copies locales de pages de mémoire pour des raisons de performances, et de que rarement de comparer les notes assurez-vous que toutes leurs copies dire la même chose. Si deux threads sur deux processeurs différents alors qu'ils peuvent avoir totalement incompatible vue sur le "même" de la mémoire.
mémoire single-threaded scénarios est généralement considéré comme "toujours" à moins que quelque chose qu'il provoque à changer. Cette intuition vous sert mal multithread processus. Si il y a plusieurs threads accèdent à la mémoire vous sont les meilleurs pour traiter la totalité de la mémoire comme dans un état constant de flux à moins que quelque chose est en l'obligeant à rester immobile. Une fois que vous commencez à penser de toute la mémoire que de changer tout le temps, il devient clair que les deux threads peuvent avoir des incohérences dans la vue. Pas de deux films de l'océan au cours d'une tempête qui se ressemblent, même si c'est la même tempête.
compilateurs sont libres de faire tout d'optimisation de code qui serait invisible sur un seul thread système. Sur un multi-thread système, ces optimisations peuvent soudainement devenir visible, ce qui peut conduire à des incohérences dans les vues de données.
Si rien de tout cela n'est pas clair, alors commencer par la lecture de mon article expliquant que "volatile" signifie en C#:
http://blogs.msdn.com/b/ericlippert/archive/2011/06/16/atomicity-volatility-and-immutability-are-different-part-three.aspx
Et lisez la section intitulée "La Nécessité Pour les Modèles de Mémoire" dans son article ici:
http://msdn.microsoft.com/en-us/magazine/cc163715.aspx
Maintenant, comme pour la question spécifique de savoir si un thread a son propre bloc de mémoire, la réponse est oui, de deux manières. Tout d'abord, depuis un thread est un point de contrôle, et depuis la pile est la réification de flux de contrôle, chaque thread a son propre millions d'octets de la pile. C'est pourquoi les threads sont si chers. Dans .NET, ces millions d'octets sont effectivement engagés dans le fichier de page chaque fois que vous créez un thread, donc soyez prudent sur la création de threads inutiles.
Deuxième, les threads ont la bien nommée "thread local storage", qui est une petite section de la mémoire associés à chaque thread le thread peut utiliser pour stocker des informations intéressantes. En C# vous utilisez le
ThreadStaticattribut pour marquer un champ comme étant local à un fil.CurrentContextpropriété d'unThreadobjet". Considérons par exemple un thread qui est en charge du fonctionnement de l'INTERFACE utilisateur actualise, et un thread qui est en charge de garder la trace des demandes de réseau, et les dix fils qui sont tous hors de dessin fractales dans les bitmaps. Vous pourriez avoir trois différentes filetage contextes, une pour chacun de ces types de tâches.La composition exacte d'un "contexte de thread" est mise en œuvre spécifique, mais en général, j'ai toujours compris un contexte du thread pour consulter l'état actuel du fil et de la façon dont il considère que la mémoire à un moment précis. C'est ce "changement de contexte", c'est.. la sauvegarde et la restauration de l'état d'un fil (c'est le contexte).
Mémoire est partagée entre les contextes.. ils font partie du même processus.
Je ne me considère pas comme un énorme expert sur le sujet.. mais c'est ce que j'ai toujours entendu le terme signifie.