2012-07-16 2 views
3

Je sais qu'il y a une méta-donnée qui stocke des informations auxiliaires qui sont utilisées pendant free(), realloc() quand nous fournissons seulement le pointeur.gestion de tas

J'ai quelques doutes sur le tas.

  • La pile est allouée par processus. Il n'y a aucun doute là-dessus, mais pas sûr de tas. Si une information de tas est globalement maintenue ailleurs par processus, il y aura un mécanisme qui contient des informations sur la mémoire allouée pour ce processus particulier.

  • Comment les informations de tas seront-elles conservées? Je suppose que le mécanisme de hachage. J'ai googlé et essayé aussi. la plupart d'entre eux l'ont expliqué comme une mise en œuvre spécifique .. comme ça.
+0

Puisque vous utilisez « processus/thread » pour signifier la même chose: Un processus est différent d'un fil.[Alors que chaque thread a sa propre pile, les threads partagent la mémoire, y compris le tas] (http://stackoverflow.com/q/1762418/274261). Les processus ne le font pas. – ArjunShankar

+0

k @ArjunShankar. laisser fil. veuillez considérer le processus. mon objectif est de savoir comment le tas est fait. – Jeyaram

+0

Très bien. Je vous suggère d'envisager de modifier votre question ensuite. Déjà une réponse a été écrite à cause de la confusion causée par l'utilisation de 'thread/process'. – ArjunShankar

Répondre

4

Le tas, comme la pile, est un processus par processus, et une chose (presque) purement utilisateur de l'espace. Le gestionnaire de segments utilise le syscall sbrk pour informer le système d'exploitation qu'il a l'intention d'augmenter la quantité de mémoire nécessaire. Cela fait peu de changement de changer une gamme de pages de "non connu" à "existant, zéro, jamais accédé" (cela signifie en réalité qu'ils n'existent toujours pas, mais le système d'exploitation prétend qu'ils le font). Lorsqu'une page est accédée pour la première fois, elle est défectueuse et le système d'exploitation extrait une page zéro du pool zéro.
(Cela peut être légèrement plus complexe, car le gestionnaire de segments de mémoire peut également réduire le segment de données si beaucoup de mémoire a été libérée par le haut, mais en fait c'est aussi simple que cela).

C'est déjà tout ce que le système d'exploitation connaît du tas. Tout le reste, comme la division de blocs, la mise en place de blocs libérés sur une liste ou une structure similaire, et la réutilisation de blocs se font à l'intérieur du gestionnaire de segments, directement ou indirectement (par exemple dans la glibc). Ce que fait exactement le gestionnaire de tas dépend de l'implémentation, il existe au moins une demi-douzaine d'implémentations de malloc bien connues qui fonctionnent de différentes manières. Voir par exemple this one ou this one ou this one.

La pile fonctionne de la même manière ou d'une manière similaire. Une certaine plage de mémoire est initialement "réservée" sans réellement réserver quoi que ce soit (c'est-à-dire sans créer de pages). Quelques pages sont validées (c'est-à-dire créées) et la dernière page est soit protégée en écriture, soit inexistante et ceci est mémorisé d'une manière spéciale. Lorsque la pile se développe et que cette dernière page est touchée, une erreur se produit. Une nouvelle page est ensuite tirée du pool zéro, à condition que la pile soit toujours dans sa taille autorisée. Lorsque le processus se termine, toutes les références à ces pages sont supprimées et (en supposant qu'elles ne sont pas partagées avec un autre processus qui contient encore une référence) transférées à une tâche d'arrière-plan de faible priorité qui les zéros et les ajoute à la zéro piscine ".

1

Oui, le tas est également par processus.

Il existe des implémentations de tas qui utilisent des tas par thread afin de réduire les conflits de verrous, mais c'est un détail d'implémentation du gestionnaire de tas (espace utilisateur).