Quelles ressources sont partagées entre les threads?

Récemment, j'ai posé une question dans une interview quelle est la différence entre un processus et un thread. Vraiment, je ne savais pas la réponse. J'ai pensé pendant une minute, et a donné un très étrange réponse.

Threads partagent le même espace mémoire, les processus ne sont pas. Après avoir répondu à ce que le recruteur m'a donné un sourire mal et a tiré les questions suivantes à moi:

Q. savez-vous qu'aux secteurs dans lesquels un programme est divisé?

Ma réponse: yep (pensais que c'était facile) de la Pile, de Données, de Code, de Tas

Q. Alors, dites-moi: quels sont les segments ne threads partagent?

Je ne pourrais pas répondre à cela et il a fini en disant tous.

S'il vous plaît, quelqu'un peut-il présenter le bon et impressionnant de réponses pour la différence entre un processus et un thread?

InformationsquelleAutor Xinus | 2009-11-19
  1. 152

    Vous êtes à peu près correct, mais threads partagent tous les segments sauf la pile. Les Threads sont indépendants les piles d'appels, cependant la mémoire dans d'autres piles de threads est toujours accessible et, en théorie, vous pourriez organiser un pointeur vers la mémoire dans un autre thread local du cadre de pile (bien que vous devriez trouver un meilleur endroit pour mettre cette mémoire!).

    • La partie intéressante est que, même si les threads sont indépendants les piles d'appels, la mémoire dans les autres piles est toujours accessible.
    • oui - je me demande s'il est possible d'accéder à la mémoire dans les autres piles entre les threads? Tant que vous êtes sûr que vous n'essayons pas de faire référence à une pile qui a été libéré, je ne suis pas sûr que je vois un problème avec elle?
    • C'est possible pour accéder à une autre pile du thread de la mémoire, mais dans l'intérêt d'un bon génie logiciel pratique, je ne dirais pas que c'est acceptable pour le faire.
    InformationsquelleAutor Greg Hewgill
  2. 49

    De Wikipédia (je pense que ça ferait une très bonne réponse pour l'interviewer :P)

    Threads différents des traditionnels
    système d'exploitation multitâche
    les processus en ce que:

    • processus sont généralement indépendantes, alors que les threads exister en tant que sous-ensembles d'un
      processus
    • processus d'importantes informations d'état, alors que plusieurs threads
      dans un processus d'action de l'état ainsi
      la mémoire et d'autres ressources
    • processus ont des espaces d'adressage différents, alors que les threads partagent leurs
      adresse de l'espace
    • processus interagissent uniquement par le biais fournies par le système inter-processus
      les mécanismes de communication.
    • Le changement de contexte entre les threads d'un même processus est généralement plus rapide
      que le changement de contexte entre
      les processus.
    • sur le point n ° 2 ci-dessus : Pour les threads également CPU maintient un contexte.
    InformationsquelleAutor Jorge Córdoba
  3. 39

    Quelque chose qui a vraiment besoin d'être souligné, c'est que, il y a deux aspects à cette question - l'aspect théorique et la mise en œuvre d'aspect.

    Tout d'abord, regardons l'aspect théorique. Vous avez besoin de comprendre ce qu'un processus est en théorie pour comprendre la différence entre un processus et un thread et ce qui est partagé entre eux.

    Nous avons la suite de l'article 2.2.2 Le Classique Modèle de Thread dans Les Systèmes d'Exploitation modernes 3e par Tanenbaum:

    Le modèle de processus est basé sur deux concepts: la ressource
    le regroupement et l'exécution. Il est parfois utile de les séparer;
    c'est là que les threads sont en....

    Il poursuit:

    Une façon de regarder un processus, c'est que c'est une façon de
    groupe de ressources liées à l'ensemble. Un processus a un espace d'adressage
    contenant le programme de texte et de données, ainsi que d'autres ressources. Ces
    des ressources peuvent inclure les fichiers ouverts, les processus enfants, dans l'attente d'alarmes,
    les gestionnaires de signaux, de la comptabilité, de l'information, et plus encore. En les mettant
    ensemble sous la forme d'un processus, ils peuvent être gérés plus facilement.
    L'autre concept, un processus est un thread d'exécution, généralement
    raccourcir à juste thread. Le thread a un compteur de programme, qui maintient
    la trace de l'instruction à exécuter suivant. Il a les registres, qui
    tenir son travail actuel variables. Il a une pile qui contient le
    l'historique d'exécution, avec une image pour chaque procédure appelée mais non
    encore de retour de. Bien qu'un thread doit s'exécuter dans un certain processus, la
    fil et ses processus sont des concepts différents, et peuvent être traités
    séparément. Les processus sont utilisés pour regrouper des ressources; les fils
    sont les entités dont l'exécution est programmée sur le CPU.

    En outre, il fournit le tableau suivant:

    Per process items             | Per thread items
------------------------------ | -----------------
Address space                 | Program counter
Global variables              | Registers
Open files                    | Stack
Child processes               | State
Pending alarms                |
Signals and signal handlers   |
Accounting information        |

    Ci-dessus est ce que vous avez besoin pour les threads de travail. Comme d'autres l'ont souligné, les choses comme les segments d'OS à charge de la mise en œuvre de détails.

    • C'est une bonne explication. Mais il devrait probablement être attachés à l'arrière de la question en quelque sorte être considéré comme une "Réponse"
    InformationsquelleAutor Robert S. Barnes
  4. 27

    Dire à l'enquêteur qu'il dépend entièrement de la mise en œuvre de l'OS.

    Prendre Windows x86 par exemple. Il y a seulement 2 segments [1], le Code et les Données. Et ils sont mappés à l'ensemble de 2 GO (linéaire, utilisateur) de l'espace d'adresse. Base=0, Limit=2 GO. Ils aurait fait un x86 mais ne permet pas un segment à la fois en Lecture/Écriture et d'Exécution. Donc, ils ont fait deux, et ensemble CS à point pour le code descripteur, et le reste (DS, ES, SS, etc) au point à l'autre [2]. Mais deux points de la même chose!

    La personne que vous interviewer avait fait un postulat caché qu'il/elle n'avait pas d'état, et c'est un truc stupide pour tirer.

    Donc en ce qui concerne

    Q. Alors, dites-moi quel segment fil
    partager?

    Les segments sont pas à la question, au moins sur Windows. Threads partagent l'ensemble de l'espace d'adressage. Il est à seulement 1 segment de pile, SS, et il indique exactement les mêmes choses que les DS, ES, et CS n' [2]. I. e. toute sanglante de l'espace utilisateur. 0-2 GO. Bien sûr, cela ne signifie pas que les threads ont seulement 1 pile. Naturellement, chacun a sa propre pile, mais x86 segments ne sont pas utilisés à cette fin.

    Peut-être *nix fait quelque chose de différent. Qui sait. La prémisse de la question est basée sur était cassé.

    1. Au moins pour l'utilisateur de l'espace.
    2. De ntsd notepad: cs=001b ss=0023 ds=0023 es=0023
    • Yep... Segments dépend de l'OS et le compilateur/linker. Parfois, il existe un segment BSS à partir du segment de DONNÉES. Parfois, il n'est RODATA (Données comme des constantes chaînes de caractères qui peuvent être dans les pages à Lecture Seulement). Certains systèmes à même de briser les DONNÉES en PETITES de DONNÉES (accessibles à partir d'une base + décalage de 16 bits) et (BEAUCOUP) de DONNÉES (32 bits décalage requis pour l'accès). Il est également possible qu'il y ait un supplément de DONNÉES TLS (Thread Magasin Local) du Segment qui est généré sur une base par thread
    • Ah, non! Vous confondez avec des segments de sections! Les articles sont la façon dont l'éditeur de liens divise le module dans les pièces (de données, de rdata, texte, sev, etc..) comme vous l'avez décrit. Mais je parle de segments, comme spécifié dans intel/amd x86 matériel. Pas du tout liés à des compilateurs/linkers. L'espoir qui fait sens.
    • Cependant, Adisak est juste sur le Fil de magasin. Il est privé de la discussion et qui n'est pas partagée. Je suis conscient de Windows OS, et pas sûr d'autres OS.
    InformationsquelleAutor Alex Budovski
  5. 19

    Généralement, les Threads sont à la lumière du poids. Si l'on divise la mémoire en trois sections, ce sera: le Code, les données et la Pile.
    Chaque processus a son propre code, les données et la pile d'articles et en raison de ce changement de contexte temps est un peu élevé. Afin de réduire les temps de changement de contexte, des gens sont venus avec le concept de thread, qui partage des Données et de segment de code avec d'autres thread/processus et il a son propre segment de PILE.

    • Vous avez oublié de tas. Tas, si je ne me trompe pas, devrait être partagé entre les threads
    InformationsquelleAutor Nimish Thakkar
  6. 16

    Un processus de code, des données, des tas et des segments de pile. Maintenant, le Pointeur d'Instruction (IP) d'un fil OU des fils de points sur le segment de code de la procédure. Les données et les tas segments sont partagés par tous les threads. Maintenant, quelle est la superficie de pile? Quelle est en fait la pile? C'est une zone créée par le processus juste pour son fil à utiliser... car les piles peuvent être utilisées dans une méthode beaucoup plus rapide que des tas etc. La pile du processus est divisée entre les threads, c'est à dire si il y a 3 fils, puis la pile du processus est divisé en 3 parties et chacune est donnée à l'3 fils. En d'autres termes, quand nous disons que chaque thread possède sa propre pile, la pile est en fait une partie de la pile du processus de la zone allouée à chaque thread. Lorsqu'un thread termine son exécution, la pile du thread est récupérée par le processus. En fait, non seulement la pile d'un processus est divisée entre les threads, mais l'ensemble des registres qu'un thread utilise comme PS, du PC et de l'état, les registres les registres du processus.
    Alors, quand il s'agit de partage, le code, les données et les tas de domaines sont partagés, alors que la pile est juste divisée entre les threads.

    InformationsquelleAutor Dhirendra Vikash Sharma
  7. 12

    Threads partagent le code et les segments de données et le tas, mais ils ne partagent pas la pile.

    • Il y a une différence entre "pouvoir accéder aux données dans la pile" et le partage de la pile. Ces fils ont leurs propres piles qui sont poussés et sauté quand ils appellent des méthodes.
    • Ils sont à la fois tout aussi valable points de vue. Oui, chaque thread possède sa propre pile dans le sens qu'il y a une correspondance entre les threads et les meules et chaque thread dispose d'un espace qu'il utilise pour sa propre pile normale d'utilisation. Mais ils sont aussi entièrement processus partagé des ressources et, si désiré, un thread peut accéder à tout autre pile du thread aussi facilement que ses propres.
    • puis-je résumer votre point comme ci-dessous: Chaque thread possède sa propre pile et la pile se compose de 2 partie - la première partie qui est partagé entre les threads avant que le processus est multi-thread, et la deuxième partie qui est rempli lorsque le thread propriétaire est en cours d'exécution.. d'Accord?
    • Il n'y a pas deux parties. Les piles sont partagés, période. Chaque thread possède sa propre pile, mais ils sont également partagés. Peut-être une bonne analogie est si vous et votre femme ont chacun une voiture, mais vous pouvez utiliser d'autres voitures tout moment vous le souhaitez.
    InformationsquelleAutor Kevin Peterson
  8. 5

    Threads partagent les données et le code si le processus n'en ont pas. La pile n'est pas partagé pour les deux.

    Processus peuvent aussi partager de la mémoire, plus précisément le code, par exemple après un Fork(), mais c'est un détail d'implémentation et (système d'exploitation) de l'optimisation. Code partagé par plusieurs processus (espérons-le) de devenir dupliqué sur le premier à écrire le code - ce qui est connu comme copy-on-write. Je ne suis pas sûr à propos de la sémantique exacte pour le code de threads, mais je suppose que le code partagé.

     De Threads Du Processus 

Pile privé privé 
Données partagées 
Code privé1 partagé2

    1 Le code est logiquement privé, mais peut être partagée pour des raisons de performances.
    2 je ne suis pas sûr à 100%.

    • Je dirais code segment (segment de texte), à la différence des données, est presque toujours en lecture seule sur la plupart des architectures.
    InformationsquelleAutor Daniel Brückner
  9. 4

    Threads partagent tout [1]. Il y a un espace d'adressage pour l'ensemble du processus.

    Chaque thread possède sa propre pile et les registres, mais de tous les threads " piles sont visibles dans l'espace d'adressage partagé.

    Si un thread alloue un objet sur sa pile, et envoie l'adresse à un autre thread, ils vont à la fois avoir l'égalité d'accès à cet objet.

    En fait, je viens de remarquer un problème plus vaste: je pense que vous êtes confus deux utilisations du mot segment.

    Le format de fichier pour un fichier exécutable (par exemple, ELF) a des sections distinctes, qui peuvent être appelés segments, contenant le code compilé (texte), des données initialisées, l'éditeur de liens symboles, les informations de débogage, etc. Il n'y a pas de tas ou de segments de pile ici, car ceux-ci sont uniquement à l'exécution des constructions.

    Ces fichier binaire segments peuvent être mappé dans l'espace d'adressage du processus séparément, avec des autorisations différentes (par exemple, en lecture seule exécutable pour le code/texte, et copie sur écriture non-exécutable pour les données initialisées).

    Zones de cet espace d'adressage sont utilisées à différentes fins, comme l'allocation de tas et des piles de threads, par convention (appliqué par votre language runtime des bibliothèques). C'est tout simplement de la mémoire, cependant, et probablement pas segmenté, sauf si vous êtes en cours d'exécution en mode virtuel 8086. Chaque pile du thread est un bloc de mémoire alloué au fil de la création, avec le courant de la pile en haut de l'adresse stockée dans un registre de pointeur de pile, et chaque thread conserve son propre pointeur de pile avec ses autres registres.

    [1] OK, je sais: le signal des masques, des TSS/DNT etc. L'adresse de l'espace, y compris tous ses cartographié des segments de programme, sont encore partagés si.

    InformationsquelleAutor Useless
  10. 2

    Dans un x86 cadre, on peut diviser que de nombreux segments (jusqu'à 2^16-1). L'ASM directives SEGMENT/prend fin le permet, et les opérateurs SEG et le DÉCALAGE permet l'initialisation des registres de segment. CS:IP sont généralement initialisé par le chargeur, mais pour la DS, ES, SS la demande est responsable de l'initialisation.
    De nombreux environnements de permettre à la soi-disant "simplifié segment de définitions", comme .code, .de données, .sev, .pile etc. et, également selon le "modèle de mémoire" (petite, grande, compacte, etc.) le chargeur initialise les registres de segment en conséquence. Généralement .de données, .sev, .pile et d'autres segments d'habitude (je n'ai pas fait cela depuis 20 ans donc je ne me souviens pas de tous) sont regroupés dans un même groupe - c'est pourquoi, généralement, DS, ES et SS points de la même zone, mais ce n'est que pour simplifier les choses.

    En général, tous les registres de segment peut avoir des valeurs différentes au moment de l'exécution.
    Donc, la question de l'entrevue était de droit: qui un de le CODE, les DONNÉES et la PILE sont partagées entre les threads. Tas de gestion est quelque chose d'autre, c'est simplement une séquence d'appels à l'OS. Mais que faire si vous ne disposez pas d'un OS, comme dans un système embarqué - pouvez-vous encore de new/delete dans votre code?

    Mon conseil aux jeunes gens de lire quelques bons assemblage de programmation livre. Il semble que l'université curriculae sont assez pauvres à cet égard.

    InformationsquelleAutor George
  11. 1

    Thread partager le tas (il y a des recherches sur fil segment spécifique), mais la mise en œuvre actuelle de partager le tas. (le code)

    InformationsquelleAutor Dani
  12. 0

    Dans les processus de tous les threads système de partage de ressources comme la Mémoire du tas etc. tandis que le Thread a sa propre pile

    De sorte que votre sna devrait être la mémoire du tas qui tous les threads partagent un processus.

    InformationsquelleAutor roshni
  13. 0

    En plus de la mémoire globale, les threads partagent également un certain nombre d'autres attributs
    (c'est à dire, ces attributs globaux d'un processus, plutôt que spécifique
    à un thread). Ces attributs sont les suivants:

    • ID de processus et de parent de l'ID de processus;
    • processus d'ID de groupe et l'ID de session;
    • terminal de contrôle;
    • informations d'identification du processus (de l'utilisateur et Id de groupe);
    • descripteurs de fichiers ouverts;
    • enregistrer les verrous créés à l'aide de fcntl();
    • signal dispositions;
    • liées au système de fichiers d'informations: umask, répertoire de travail courant, et le répertoire de racine;
    • des compteurs d'intervalle (setitimer()) et les minuteurs POSIX (timer_create());
    • Sémaphores System V, annuler (semadj) values (Section de 47,8);
    • les limites des ressources;
    • Temps CPU consommé (retourné par times());
    • ressources consommées (retourné par getrusage()); et
    • valeur de nice (défini par setpriority() et nice()).

    Parmi les attributs qui sont distincts pour chaque thread sont les
    suivantes:

    • ID de thread (Article 29.5);
    • masque de signal;
    • fil de données spécifiques (Article 31.3);
    • suppléant signal de pile (sigaltstack());
    • la variable errno;
    • à virgule flottante de l'environnement (voir fenv(3));
    • de planification en temps réel de priorités et de politiques (Articles 35.2 et 35.3);
    • De l'affinité CPU (spécifique à Linux, décrit dans l'Article 35.4);
    • capacités (spécifique à Linux, décrit dans le Chapitre 39); et
    • pile (variables locales et de l'appel de la fonction de liaison de l'information).

    Extrait De: Le Linux Programming Interface): Interface de Linux et UNIX Manuel de Programmation Système , Michael Kerrisk, page 619

    InformationsquelleAutor snr