L'ordonnanceur du noyau fait attention � s�parer les processus dans le temps. Votre syst�me d'exploitation les divise aussi dans l'espace, de telle mani�re que ces processus n'empi�tent pas sur la m�moire de travail des autres. Ces choses que votre syst�me d'exploitation r�alise sont appel�es gestion de la m�moire.
Chaque processus de votre 'troupeau' a besoin de son propre espace m�moire afin de mettre son code et de garder des variables et leur r�sultat. Vous pouvez imaginer cet ensemble constitu� d'un segment de code accessible en lecture uniquement (contenant les instrucions du processus) et un segment de donn�es accessible en �criture (contenant toutes les variables du processus). Le segment de donn�es est v�ritablement propre � chaque processus, mais si deux processus ex�cutent le m�me code, Unix s'arrange automatiquement pour qu'ils partagent le m�me segment de code dans un soucis d'efficacit�.
L'efficacit� est importante car la m�moire est ch�re. Quelquefois, vous ne disposez pas de suffisamment de m�moire pour faire tenir tous les programmes, sp�cialement si vous utilisez un gros programme comme un serveur X-WINDOW. Pour contourner cela, Unix utilise une strat�gie appel�e m�moire virtuelle. Cela n'essaie pas de faire tenir tout le code et les donn�es d'un processus en m�moire. Cependant, il garde seulement un espace de travail ; le reste de l'�tat du processus est laiss� dans un endroit sp�cial sur votre disque : l'espace d'�change (swap space).
Lorsque le processus s'ex�cute, Unix essaie d'anticiper comment l' espace de travail changera, et ne chargera en m�moire que les morceaux dont il a besoin. Faire cela efficacement est compliqu� et d�licat, je n'essaierai pas de le d�crire ici -- mais cela d�pend du fait que le code et les r�f�rences aux donn�es peuvent arriver en blocs, avec chaque nouveau r�f�ren�ant vraisemblablement un proche ou un ancien. Ainsi, si Unix garde le code ou les donn�es fr�quemment (ou r�cemment) utilis�s, vous gagnerez du temps.
Notez que dans le pass�, le "quelquefois" que nous employons deux paragraphes plus haut �tait "souvent" voire "toujours", -- la taille de la m�moire �tait habituellement petite par rapport � la taille des programmes en cours d'ex�cution, de telle mani�re que les �changes entre le disque et la m�moire ("swapping") �taient fr�quents. La m�moire est beaucoup moins ch�re de nos jours et m�me les machines bas de gamme en sont bien dot�es. Sur les machines mono-utilisateur avec 64Mo de m�moire, il est possible de faire tourner X-WINDOW et un m�lange de programmes sans jamais swapper.
M�me dans cette situation joyeuse, la part du syst�me d'exploitation appel�e le gestionnaire de m�moire a un important travail � faire. Il doit �tre s�r que les programmes ne peuvent modifier que leurs segments de m�moire -- ce qui emp�che un code erron� ou malicieux dans un programme de ramasser les donn�es dans un autre. Pour faire cela, il conserve une table des segments de donn�es et de code. La table est mise � jour chaque fois qu'un processus demande de la m�moire ou en lib�re (habituellement plus tard lorsqu'il se termine).
Cette table est utilis�e pour passer des commandes � une partie sp�cialis�e du mat�riel sous-jacent appel�e un UGM (MMU) ou unit� de gestion m�moire (memory management unit). Les processeurs modernes disposent de MMUs int�gr�s. Le MMU a la facult� de mettre des barri�res autour de zones m�moire, ainsi une r�f�rence en "dehors des clous" sera refus�e et g�n�rera une interruption sp�ciale pour �tre trait�e.
Si vous avez d�j� vu le message Unix qui dit "Segmentation fault", "core dumped" ou quelque chose de similaire, c'est exactement ce qu'il se passe ; un programme en cours d'ex�cution a tent� d'acc�der � de la m�moire en dehors de son segment et a provoqu� une interruption fatale. Cela indique un bug dans le code du programme ; le core dump laisse une information en vue d'un diagnostic � l'attention du programmeur afin qu'il puisse trouver la trace de son erreur.
Hosting by: Hurra Communications GmbH
Generated: 2007-01-26 18:01:24