Comment la mémoire est allouée en cas de frai d'un nouveau thread, c'est-à-dire comment le tas de mémoire, la pile de mémoire et les threads sont liés? Je sais que c'est fondamental (concept de framework .NET), mais je ne suis pas très conscient de ce concept.
4 Réponses :
Chaque fil a sa propre pile, mais tous les threads partagent le tas.
La pile appartient au contexte du fil. Le tas appartient au processus, il est donc partagé entre les threads.
Il est fondamental beaucoup plus profond que .NET. Les threads sont des objets natifs du système d'exploitation. Ce qu'on appelle le thread géré est juste enracinant autour du fil natif.
Retour à votre question. Le tas de mémoire est partagé des fils d'accrocs du même processus car ils sont situés dans un seul espace mémoire virtuel. Les piles sont individuelles.
Il est vraiment difficile de répondre à cette question en raison de la mise en œuvre de threads .NET. Il n'y a pas nécessairement une implémentation 1-1 entre les threads indigènes gérés et correspondants. Le CLR est libre d'utiliser plusieurs threads natifs pour mettre en place un seul fil géré. Ainsi, l'allocation d'un nouveau fil géré ne provoque pas nécessairement qu'un fil indigène soit engendré. Cela peut supposer un simple assumer un existant.
Pouvez-vous nous dire pourquoi cela est préoccupé par vous? Peut-être que cela nous mènera à une meilleure réponse.
Je pense que la mise en œuvre des threads de Windows CLR est très proche de Native. Veuillez préciser l'exemple de la cartographie non 1-1.
@Andrey Ce n'est malheureusement pas le cas. Considérons l'ajout de thread.Managedthreid in 2.0. Cette propriété a été ajoutée précisément dans le but de distinguer les fils gérés de leur potentiellement de nombreux soutes natales.
@Andrey (suite) Lorsque le thread géré est une STA, je ne crois pas que le CLR peut changer ou changera le fil natif car les objets COM créés auraient une affinité de fil au fil natif. Mais dans le MTA, il n'y a pas de problème d'affinité et le CLR peut changer librement le fil natif du support.
J'essayais de trouver le nombre maximal de thread qu'une application Windows peut avoir sans aucune dégradation de performances notable (coût). Mais essayait d'effacer les bases d'abord, comme dans la manière dont l'attribution de la mémoire est effectuée lorsqu'un nouveau fil est engendré. Je comprends que le frai d'un fil est coûteux.
Lorsque vous faites de nouveaux threads (), un nouveau thread est vraiment généré. Vous pouvez voir que c'est un débogage ou un gestionnaire de tâches. Si vous voulez trouver un nombre maximal de threads, je les saisis en boucle et voyez ce qui a été le nombre maximal de comptes
@JaredPar j'ai lu toutes ces choses à propos de Managédheadid mais je n'ai jamais vu quelque chose à propos de l'échange de threads ni de cartographie non 1-1 dans la vie réelle, bien que j'écris beaucoup de code multithread. Aussi, comment TLS et d'autres que le thread Stuff fonctionnent-ils?
@Jared: C'était un projet pour le groupe SQL Server. Il a été abandonné, ils ne pouvaient pas le faire fiable. À l'heure actuelle, tous les hôtes CLR connus ont un mappage de 1 à 1 entre threads géré et threads OS. Link: blogs.msdn.com/dinoviehland/archive/2005/ 09/15 / 469642.aspx
@Andrey, vous devez différencier les TLS natifs et gérés. Ce modèle aurait évidemment des implications sur le code TLS natif. Le modèle TLS géré cependant, thread.allocateataslot est mis en œuvre indépendamment des TLS natifs.
@nobugz Il fait toujours partie du modèle d'hébergement CLR pour permettre à plusieurs threads natifs de récupérer un fil géré donné. Le mode Fibre a été coupé mais cette fonctionnalité a été maintenue dans le modèle d'hébergement.
@Jarededpar Vous pourriez dire les bonnes choses, mais c'est très théorique. Veuillez donner l'exemple ou l'article, avec l'exemple où la cartographie non 1-1 peut être touchée.