diff --git a/Theorie/Fichiers/fichiers.rst b/Theorie/Fichiers/fichiers.rst index 8ea4a6d4c7dfb4fd611f5d73a0a3af45f3b76328..fcdbda058888302cdd1695efff6494d0909bde5e 100644 --- a/Theorie/Fichiers/fichiers.rst +++ b/Theorie/Fichiers/fichiers.rst @@ -177,8 +177,7 @@ Il existe plusieurs appels systèmes et fonctions de la librairie standard qui p - l'appel système `mkdir(2)`_ permet de créer un répertoire alors que l'appel système `rmdir(2)`_ permet d'en supprimer un - les fonctions de la librairie `opendir(3)`_, `closedir(3)`_, et `readdir(3)`_ permettent de consulter le contenu de répertoires. -.. - Les fonctions de manipulation des répertoires méritent que l'on s'y attarde un peu. Un répertoire est un fichier qui a une structure spéciale. Ces trois fonctions permettent d'en extraire de l'information en respectant le format d'un répertoire. Pour accéder à un répertoire, il faut d'abord l'ouvrir en utilisant `opendir(3)`_. La fonction `readdir(3)`_ permet d'accéder aux différentes entrées de ce répertoire et `closedir(3)`_ doit être utilisée lorsque l'accès n'est plus nécessaire. La fonction `readdir(3)`_ permet de manipuler la structure ``dirent`` qui est définie dans `bits/dirent.h`_. +Les fonctions de manipulation des répertoires méritent que l'on s'y attarde un peu. Un répertoire est un fichier qui a une structure spéciale. Ces trois fonctions permettent d'en extraire de l'information en respectant le format d'un répertoire. Pour accéder à un répertoire, il faut d'abord l'ouvrir en utilisant `opendir(3)`_. La fonction `readdir(3)`_ permet d'accéder aux différentes entrées de ce répertoire et `closedir(3)`_ doit être utilisée lorsque l'accès n'est plus nécessaire. La fonction `readdir(3)`_ permet de manipuler la structure ``dirent`` qui est définie dans `bits/dirent.h`_. .. code-block:: c @@ -197,10 +196,11 @@ Il existe plusieurs appels systèmes et fonctions de la librairie standard qui p l'inode métadonnée - Cette structure comprend le numéro de l'inode, c'est-à -dire la métadonnée qui contient les informations relatives au fichier/répertoire, la position de l'entrée ``dirent`` qui suite, la longueur de l'entrée, son type et le nom de l'entrée dans le répertoire. Chaque appel à `readdir(3)`_ retourne un pointeur vers une structure de ce type. +Cette structure comprend le numéro de l'inode, c'est-à -dire la métadonnée qui contient les informations relatives au fichier/répertoire, la position de l'entrée ``dirent`` qui suite, la longueur de l'entrée, son type et le nom de l'entrée dans le répertoire. Chaque appel à `readdir(3)`_ retourne un pointeur vers une structure de ce type. - L'extrait de code ci-dessous permet de lister tous les fichiers présents dans le répertoire ``name``. +L'extrait de code ci-dessous permet de lister tous les fichiers présents dans le répertoire ``name``. + .. literalinclude:: /Fichiers/src/readdir.c :encoding: utf-8 @@ -208,13 +208,14 @@ Il existe plusieurs appels systèmes et fonctions de la librairie standard qui p :start-after: ///AAA :end-before: ///BBB - - La lecture d'un répertoire avec `readdir(3)`_ commence au début de ce répertoire. A chaque appel à `readdir(3)`_, le programme appelant récupère un pointeur vers une zone mémoire contenant une structure ``dirent`` avec l'entrée suivante du répertoire ou ``NULL`` lorsque la fin du répertoire est atteinte. Si une fonction doit relire à nouveau un répertoire, cela peut se faire en utilisant `seekdir(3)`_ ou `rewinddir(3)`_. + + +La lecture d'un répertoire avec `readdir(3)`_ commence au début de ce répertoire. A chaque appel à `readdir(3)`_, le programme appelant récupère un pointeur vers une zone mémoire contenant une structure ``dirent`` avec l'entrée suivante du répertoire ou ``NULL`` lorsque la fin du répertoire est atteinte. Si une fonction doit relire à nouveau un répertoire, cela peut se faire en utilisant `seekdir(3)`_ ou `rewinddir(3)`_. - .. note:: `readdir(3)`_ et les threads +.. note:: `readdir(3)`_ et les threads - La fonction `readdir(3)`_ est un exemple de fonction non-réentrante qu'il faut éviter d'utiliser dans une application dont plusieurs threads doivent pouvoir parcourir le même répertoire. Ce problème est causé par l'utilisation d'une zone de mémoire ``static`` afin de stocker la structure dont le pointeur est retourné par `readdir(3)`_. Dans une application utilisant plusieurs threads, il faut utiliser la fonction `readdir_r(3)`_ : + La fonction `readdir(3)`_ est un exemple de fonction non-réentrante qu'il faut éviter d'utiliser dans une application dont plusieurs threads doivent pouvoir parcourir le même répertoire. Ce problème est causé par l'utilisation d'une zone de mémoire ``static`` afin de stocker la structure dont le pointeur est retourné par `readdir(3)`_. Dans une application utilisant plusieurs threads, il faut utiliser la fonction `readdir_r(3)`_ : .. code-block:: c @@ -225,7 +226,7 @@ Il existe plusieurs appels systèmes et fonctions de la librairie standard qui p Cette fonction prend comme arguments le pointeur ``entry`` vers un buffer propre à l'appelant qui permet de stocker le résultat de `readdir_r(3)`_. - Les appels systèmes `link(2)`_ et `unlink(2)`_ sont un peu particuliers et méritent une description plus détaillée. Sous Unix, un :term:`inode` est associé à chaque fichier mais l':term:`inode` ne contient pas le nom de fichier parmi les méta-données qu'il stocke. Par contre, chaque :term:`inode` contient un compteur (``nlinks``) du nombre de liens vers un fichier. Cela permet d'avoir une seule copie d'un fichier qui est accessible depuis plusieurs répertoires. Pour comprendre cette utilisation des liens sur un système de fichiers Unix, considérons le scénario suivant. +Les appels systèmes `link(2)`_ et `unlink(2)`_ sont un peu particuliers et méritent une description plus détaillée. Sous Unix, un :term:`inode` est associé à chaque fichier mais l':term:`inode` ne contient pas le nom de fichier parmi les méta-données qu'il stocke. Par contre, chaque :term:`inode` contient un compteur (``nlinks``) du nombre de liens vers un fichier. Cela permet d'avoir une seule copie d'un fichier qui est accessible depuis plusieurs répertoires. Pour comprendre cette utilisation des liens sur un système de fichiers Unix, considérons le scénario suivant. .. code-block:: console @@ -301,8 +302,9 @@ En plus de l'un des trois drapeaux ci-dessus, il est également possible de spé - ``O_CREAT`` : indique que si le fichier n'existe pas, il doit être créé lors de l'exécution de l'appel système `open(2)`_. L'appel système `creat(2)`_ peut également être utilisé pour créer un nouveau fichier. Lorsque le drapeau ``O_CREAT`` est spécifié, l'appel système `open(2)`_ prend comme troisième argument les permissions du fichier qui doit être créé. Celles-ci sont spécifiées de la même façon que pour l'appel système `chmod(2)`_. Si elles ne sont pas spécifiées, le fichier est ouvert avec comme permissions les permissions par défaut du processus définies par l'appel système `umask(2)`_ - ``O_APPEND`` : indique que le fichier est ouvert de façon à ce que les données écrites dans le fichier par l'appel système `write(2)`_ s'ajoutent à la fin du fichier. - ``O_TRUNC`` : indique que si le fichier existe déjà et qu'il est ouvert en écriture, alors le contenu du fichier doit être supprimé avant que le processus ne commence à y accéder. -.. - ``O_CLOEXEC`` : ce drapeau qui est spécifique à Linux indique que le fichier doit être automatiquement fermé lors de l'exécution de l'appel système `execve(2)`_. Normalement, les fichiers qui ont été ouverts par `open(2)`_ restent ouverts lors de l'exécution de `execve(2)`_. - ``O_SYNC`` : ce drapeau indique que toutes les opérations d'écriture sur le fichier doivent être effectuées immédiatement sur le dispositif de stockage sans être mises en attente dans les buffers du noyau du système d'exploitation + .. - ``O_CLOEXEC`` : ce drapeau qui est spécifique à Linux indique que le fichier doit être automatiquement fermé lors de l'exécution de l'appel système `execve(2)`_. Normalement, les fichiers qui ont été ouverts par `open(2)`_ restent ouverts lors de l'exécution de `execve(2)`_. + Ces différents drapeaux binaires doivent être combinés en utilisant une disjonction logique entre les différents drapeaux. Ainsi, ``O_CREAT|O_RDWR`` correspond à l'ouverture d'un fichier qui doit à la fois être créé si il n'existe pas et ouvert en lecture et écriture. @@ -331,6 +333,7 @@ Toutes les opérations qui sont faites sur un fichier se font en utilisant le :t Tout processus doit correctement fermer tous les fichiers qu'il a utilisé. Par défaut, le système d'exploitation ferme automatiquement les descripteurs de fichiers correspondant ``0``, ``1`` et ``2`` lorsqu'un processus se termine. Les autres descripteurs de fichiers doivent être explicitement fermés par le processus. Si nécessaire, cela peut se faire en enregistrant une fonction permettant de fermer correctement les fichiers ouverts via `atexit(3)`_. Il faut noter que par défaut un appel à `execve(2)`_ ne ferme pas les descripteurs de fichiers ouverts par le processus. C'est nécessaire pour permettre au programme exécuté d'avoir les entrées et sorties standard voulues. .. , outre les références vers l':term:`inode` du fichier, + Lorsqu'un fichier a été ouvert, le noyau du système d'exploitation maintient un :term:`offset pointer`. Cet :term:`offset pointer` est la position actuelle de la tête de lecture/écriture du fichier. Lorsqu'un fichier est ouvert, son :term:`offset pointer` est positionné au premier octet du fichier, sauf si le drapeau ``O_APPEND`` a été spécifié lors de l'ouverture du fichier, dans ce cas l':term:`offset pointer` est positionné juste après le dernier octet du fichier de façon à ce qu'une écriture s'ajoute à la suite du fichier. Les deux appels systèmes permettant de lire et d'écrire dans un fichier sont respectivement `read(2)`_ et `write(2)`_. @@ -429,6 +432,68 @@ Cet appel système prend trois arguments. Le premier est le :term:`descripteur d Dans certains cas il est utile de pouvoir dupliquer un descripteur de fichier. C'est possible avec les appels systèmes `dup(2)`_ et `dup2(2)`_. L'appel système `dup(2)`_ prend comme argument un descripteur de fichier et retourne le plus petit descripteur de fichier libre. Lorsqu'un descripteur de fichier a été dupliqué avec `dup(2)`_ les deux descripteurs de fichiers partagent le même :term:`offset pointer` et les mêmes modes d'accès au fichier. +.. _mmap: + +Fichiers mappés en mémoire +-------------------------- + +Lorsqu'un processus Unix veut lire ou écrire des données dans un fichier, il utilise en général les appels systèmes `open(2)`_, `read(2)`_, `write(2)`_ et `close(2)`_ directement ou à travers une librairie de plus haut niveau comme la libraire d'entrées/sorties standard. Ce n'est pas la seule façon pour accéder à des données sur un dispositif de stockage. Grâce à la mémoire virtuelle, il est possible de placer le contenu d'un fichier ou d'une partie de fichier dans une zone de la mémoire du processus. Cette opération peut être effectuée en utilisant l'appel système `mmap(2)`_. Cet appel système permet de rendre un fichier accessibles directement dans la mémoire du processus. + + + +.. code-block:: c + + #include <sys/mman.h> + + void *mmap(void *addr, size_t length, int prot, int flags, + int fd, off_t offset); + + +L'appel système `mmap(2)`_ prend six arguments, c'est un des appels systèmes qui utilise le plus d'arguments. Il permet de rendre accessible une portion d'un fichier via la mémoire d'un processus. Le cinquième argument est le descripteur du fichier qui doit être mappé. Celui-ci doit avoir été préalablement ouvert avec l'appel système `open(2)`_. Le sixième argument spécifie l'offset à partir duquel le fichier doit être mappé, ``0`` correspondant au début du fichier. Le premier argument est l'adresse à laquelle la première page du fichier doit être mappée. Généralement, cet argument est mis à ``NULL`` de façon à laisser le noyau choisir l'adresse la plus appropriée. Le deuxième argument est la longueur de la zone du fichier qui doit être mappée en mémoire. Le troisième argument contient des drapeaux qui spécifient les permissions d'accès aux données mappées. Cet argument peut soit être ``PROT_NONE``, ce qui indique que la page est inaccessible soit une permission classique : + + - ``PROT_EXEC``, les pages mappées contiennent des instructions qui peuvent être exécutées + - ``PROT_READ``, les pages mappées contiennent des données qui peuvent être lues + - ``PROT_WRITE``, les pages mappées contiennent des données qui peuvent être modifiées + +Ces drapeaux peuvent être combinés avec une disjonction logique. Le quatrième argument est un drapeau qui indique comment les pages doivent être mappées en mémoire. Ce drapeau spécifie comment un fichier qui est mappé par deux ou plusieurs processus doit être traité. Deux drapeaux sont possibles : + + - ``MAP_PRIVATE``. Dans ce cas, le fichier est mappé dans chaque processus, mais si un processus modifie une page, cette modification n'est pas répercutée aux autres processus qui ont mappé le même fichier. + - ``MAP_SHARED``. Dans ce cas, plusieurs processus peuvent accéder et modifier la page qui est mappée en mémoire. Lorsqu'un processus modifie le contenu d'une page, la modification est visible aux autres processus. Par contre, le fichier qui est mappé en mémoire n'est modifié que lorsque le noyau du système d'exploitation décide d'écrire les données modifiées sur le dispositif de stockage. Ces écritures dépendent de nombreux facteurs, dont la charge du système. Si un processus veut être sûr des écritures sur disque des modifications qu'il a fait à un fichier mappé un mémoire, il doit exécuter l'appel système `msync(2)`_ ou supprimer le mapping via `munmap(2)`_. + +.. spelling:: + + mapping + +Ces deux drapeaux peuvent dans certains cas particuliers être combinés avec d'autres drapeaux définis dans la page de manuel de `mmap(2)`_. + +Lorsque `mmap(2)`_ réussit, il retourne l'adresse du début de la zone mappée en mémoire. En cas d'erreur, la constante ``MAP_FAILED`` est retournée et ``errno`` est mis à jour en conséquence. + +L'appel système `msync(2)`_ permet de forcer l'écriture sur disque d'une zone mappée en mémoire. Le premier argument est l'adresse du début de la zone qui doit être écrite sur disque. Le deuxième argument est la longueur de la zone qui doit être écrite sur le disque. Enfin, le dernier contient un drapeau qui spécifie comment les pages correspondantes doivent être écrites sur le disque. Le drapeau ``MS_SYNC`` indique que l'appel `msync(2)`_ doit bloquer tant que les données n'ont pas été écrites. Le drapeau ``MS_ASYNC`` indique au noyau que l'écriture doit être démarrée, mais l'appel système peut se terminer avant que toutes les pages modifiées aient été écrites sur disque. + +.. code-block:: c + + #include <sys/mman.h> + int msync(void *addr, size_t length, int flags); + + +Lorsqu'un processus a fini d'utiliser un fichier mappé en mémoire, il doit d'abord supprimer le mapping en utilisant l'appel système `munmap(2)`_. Cet appel système prend deux arguments. Le premier doit être un multiple de la taille d'une page [#ftaillepage]_. Le second est la taille de la zone pour laquelle le mapping doit être retiré. + +.. code-block:: c + + #include <sys/mman.h> + + int munmap(void *addr, size_t length); + + +A titre d'exemple d'utilisation de `mmap(2)`_ et `munmap(2)`_, le programme ci-dessous implémente l'équivalent de la commande `cp(1)`_. Il prend comme arguments deux noms de fichiers et copie le contenu du premier dans le second. La copie se fait en mappant le premier fichier entièrement en mémoire et en utilisant la fonction `memcpy(3)`_ pour réaliser la copie. Cette solution fonctionne avec de petits fichiers. Avec de gros fichiers, elle n'est pas très efficace car tout le fichier doit être mappé en mémoire. + +.. literalinclude:: /MemoireVirtuelle/src/cp2.c + :encoding: utf-8 + :language: c + :start-after: ///AAA + + + .. rubric:: Footnotes @@ -444,5 +509,5 @@ Cet appel système prend trois arguments. Le premier est le :term:`descripteur d .. [#fendianfig] Source : http://en.wikipedia.org/wiki/Endianness - +.. [#ftaillepage] Il est possible d'obtenir la taille des pages utilisée sur un système via les appels `sysconf(3)`_ ou `getpagesize(2)`_ diff --git a/Theorie/Threads/threads.rst b/Theorie/Threads/threads.rst index ef53ec49904408abf7274921f4a0444e2b568c2d..96ebd54a35757e2b45e7cb9210cf7df27e54b0c2 100644 --- a/Theorie/Threads/threads.rst +++ b/Theorie/Threads/threads.rst @@ -81,6 +81,8 @@ Considérons la fonction ``f`` : } return m; } + + .. En assembleur, cette fonction se traduit en : @@ -111,9 +113,11 @@ Considérons la fonction ``f`` : addl $16, %esp ret + .. il faut non seulement qu'il implémente chacune de ces instructions, mais également qu'il puisse accéder : + + Pour qu'un processeur puisse exécuter cette séquence d'instructions, il faut qu'il puisse accéder : -.. il faut non seulement qu'il implémente chacune de ces instructions, mais également qu'il puisse accéder : - à la mémoire contenant les instructions à exécuter - à la mémoire contenant les données manipulées par cette séquence d'instruction. Pour rappel, cette mémoire est divisée en plusieurs parties : @@ -123,7 +127,8 @@ Pour qu'un processeur puisse exécuter cette séquence d'instructions, il faut q - la pile - - aux registres, des zone de mémoire très rapide (mais peu nombreuses par soucis technique) se trouvant sur le processeur qui permettent de stocker entre autre : l'addresse de l'instruction à exécuter, des résultats intermédaires obtenus durant l'exécution d'un instruction ou encore des informations sur la pile. + - aux registres, des zones de mémoire très rapide (mais peu nombreuses) se trouvant sur le processeur qui permettent de stocker entre autres : l'adresse de l'instruction à exécuter, des résultats intermédiaires obtenus durant l'exécution d'un instruction ou encore des informations sur la pile. + .. et plus particulièrement, il doit accéder : .. - aux registres de données pour stocker les résultats de chacune des instructions diff --git a/Theorie/Threads/threads2.rst b/Theorie/Threads/threads2.rst index 2ee6cdcd4d3b880c730354d71c856caadb4ca5c8..8448971f92bdb772caa39bea9c3221396f7d923e 100644 --- a/Theorie/Threads/threads2.rst +++ b/Theorie/Threads/threads2.rst @@ -17,7 +17,7 @@ Lorsque un programme a été décomposé en plusieurs threads, ceux-ci ne sont e Organisation de la mémoire après la création d'un thread POSIX -Le programme principal et le thread qu'il a créé partagent trois zones de la mémoire : le :term:`segment text` qui comprend l'ensemble des instructions qui composent le programme, le :term:`segment de données` qui comprend toutes les données statiques , initialisées ou non (c'est-à -dire les constantes, les variables globales ou encore les chaines de caractère) et enfin le :term:`heap`. Autant le programme principal que son thread peuvent accéder à n'importe quelle information se trouvant en mémoire dans ces zones. Par contre, le programme principal et le thread qu'il vient de créer ont chacun leur propre contexte et leur propre pile. +Le programme principal et le thread qu'il a créé partagent trois zones de la mémoire : le :term:`segment text` qui comprend l'ensemble des instructions qui composent le programme, le :term:`segment de données` qui comprend toutes les données statiques , initialisées ou non (c'est-à -dire les constantes, les variables globales ou encore les chaînes de caractère) et enfin le :term:`heap`. Autant le programme principal que son thread peuvent accéder à n'importe quelle information se trouvant en mémoire dans ces zones. Par contre, le programme principal et le thread qu'il vient de créer ont chacun leur propre contexte et leur propre pile. La première façon pour un processus de communiquer avec un thread qu'il a lancé est d'utiliser les arguments de la fonction de démarrage du thread et la valeur retournée par le thread que le processus principal peut récupérer via l'appel à `pthread_join(3posix)`_. C'est un canal de communication très limité qui ne permet pas d'échange d'information pendant l'exécution du thread. diff --git a/Theorie/bib.rst b/Theorie/bib.rst index 1d8a14dd7c96ec02bf09a3636ea5e61e25e3aa66..9428a3455fdfd6fd648db5ee8e1847c97703d7ce 100644 --- a/Theorie/bib.rst +++ b/Theorie/bib.rst @@ -173,3 +173,5 @@ Bibliographie Prentice Walls Microsystems + and + Sun diff --git a/Theorie/glossaire.rst b/Theorie/glossaire.rst index 577db1113704e9c533f2bdf4c2a8ae5f2bfde0af..47a8ca0de9827f05fc5a1430d77e2b72fe19bef6 100644 --- a/Theorie/glossaire.rst +++ b/Theorie/glossaire.rst @@ -32,7 +32,7 @@ Glossaire Compilateur pour la langage C développé par un groupe de volontaires qui est diffusé depuis http://gcc.gnu.org gcc est utilisé dans plusieurs systèmes d'exploitation de type Unix, comme MacOS, Linux ou FreeBSD. Il existe d'autres compilateurs C. Une liste non-exhaustive est maintenue sur http://en.wikipedia.org/wiki/List_of_compilers#C_compilers llvm - Ensemble de compilateurs pour différents langages de programmation et différents processeurs développé par un groupe de volontaire. llvm est distrubé depuis http://llvm.org/ + Ensemble de compilateurs pour différents langages de programmation et différents processeurs développé par un groupe de volontaire. ``llvm`` est distribué depuis http://llvm.org/ cpp préprocesseur @@ -154,7 +154,7 @@ Glossaire Fichier contenant des signatures de fonctions, des déclarations de types de données, des variables globales, permettant d'utiliser une librairie ou un API. segmentation fault - Erreur à l'exécution à compléter + Erreur à l'exécution causée par un accès à une adresse mémoire non-autorisée pour le programme. NOT négation @@ -182,7 +182,7 @@ Glossaire Zone d'un programme dans laquelle une variable est déclarée. portée locale - Une variable ayant une portée locale est accessible uniquement dans le bloc dans lequelle elle est définie. + Une variable ayant une portée locale est accessible uniquement dans le bloc dans laquelle elle est définie. portée globale Une variable ayant une portée globale est accessible dans tout le programme. @@ -262,40 +262,40 @@ Glossaire Registre spécial du processeur qui contient en permanence l'adresse de l'instruction en cours d'exécution. Le contenu de ce registre est incrémenté après chaque instruction et modifié par les instructions de saut. makefile - à compléter + Fichier décrivant la façon dont `make(1)`_ doit compiler un programme. fichier - à compléter + Une séquence composée d'un nombre entier d'octets stockée sur un dispositif de stockage. Un fichier est identifié par son nom et sa position dans l'arborescence du système de fichiers. fichier objet - à compléter + Fichier résultat de la compilation d'une partie de programme. Ce fichier contient les instructions en langage machine à exécuter ainsi que les informations relatives aux différents symboles (variables, fonctions, ...) qui y sont définis. linker - à compléter + Editeur de liens. Partie du compilateur c permettant de combiner plusieurs fichiers objet en un exécutable. errno - à compléter + Variable globale mise à jour par certains appels systèmes et fonctions de la librairie standard en cas d'erreur. Voir `errno(3)`_ loi de Moore - à compléter + Voir https://fr.wikipedia.org/wiki/Loi_de_Moore kHz - à compléter + Mesure de fréquence en milliers de répétitions par seconde. MHz - à compléter + Mesure de fréquence en millions de répétitions par seconde. GHz - à compléter + Mesure de fréquence en milliards de répétitions par seconde. MIPS Million d'instructions par seconde benchmark - à compléter + Ensemble de programmes permettant d'évaluer les performances d'un système informatique. multi-coeurs - à compléter + Processeur contenant plusieurs unités permettant d'exécuter simultanément des instructions de programmes différents. multithreadé Programme utilisant plusieurs threads. @@ -304,94 +304,94 @@ Glossaire Partie de programme ne pouvant pas être exécutée simultanément par deux threads différents. exclusion mutuelle - à compléter + Zone d'un programme multithreadé qui ne peut pas être exécutée par plus d'un thread à la fois. sûreté safety - à compléter + Propriété d'un programme informatique. Dans le problème de l'exclusion mutuelle, une propriété de sûreté est que deux threads ne seront jamais dans la même section critique. liveness vivacité - à compléter + Propriété d'un programme informatique. Dans le problème de l'exclusion mutuelle, une propriété de vivacité est qu'un thread qui souhaite entrer en section critique finira par y accéder. multitâche multitasking - à compléter + Capacité d'exécuter plusieurs programmes simultanément. contexte - à compléter + Structure de données maintenue pas le noyau du système d'exploitation qui contient toutes les informations nécessaires pour poursuivre l'exécution d'un programme. changement de contexte - à compléter + Passage de l'exécution du programme A au programme B. interruption - à compléter + Signal extérieur (horloge, opération d'entrée/sortie, ...) qui force le processeur à arrêter l'exécution du programme en cours pour exécuter une routine du système d'exploitation et traiter l'interruption. scheduler - à compléter + Ordonnanceur. Algorithme utilisé par le noyau du système d'exploitation pour sélectionner le prochain programme à exécuter après une interruption d'horloge ou un appel système bloquant. round-robin - à compléter + Voir https://fr.wikipedia.org/wiki/Round-robin_(informatique) livelock - à compléter + Voir https://en.wikipedia.org/wiki/Deadlock#Livelock opération atomique - à compléter + Opération ne pouvant être interrompue. deadlock - à compléter + Voir https://en.wikipedia.org/wiki/Deadlock mutex - à compléter + Primitive de synchronisation permettant d'empêcher que deux threads accèdent simultanément à une même section critique. appel système - à compléter + Fonction primitive fournie par le noyau du système d'exploitation et pouvant être appelée directement par les programmes applicatifs. appel système bloquant - à compléter + Appel système qui ne retourne par de résultat immédiat. Dans ce cas, le noyau du système d'exploitation sélectionne un autre processus via le :term:`scheduler` en attendant que le résultat de l'appel système soit disponible. sémaphore - à compléter + Primitive de synchronisation permettant notamment l'exclusion mutuelle. Voir notamment [Downey2008]_ thread-safe - à compléter + Une fonction est dite thread-safe si elle peut être simultanément exécutée sans contrainte par différents threads d'un même programme. loi de Amdahl - à compléter + Voir https://fr.wikipedia.org/wiki/Loi_d%27Amdahl static library librairie statique - à compléter + Une librairie est statiquement liée à un programme exécutable lorsque tout son code est intégré dans l'exécutable. Voir les arguments ``static`` dans `gcc(1)`_ shared library librairie dynamique librairie partagée - à compléter + Lorsqu'un librairie est dynamiquement liée à un programme exécutable, le code de celui-ci ne contient pas les instructions de la librairie, mais celle-ci est automatiquement chargée lors de chaque exécution du programme. Cela permet d'avoir une seule copie de chaque librairie. C'est la solution utilisée par défaut sous Linux. descripteur de fichier - à compléter + Identifiant (entier) retourné par le noyau du système d'exploitation lors de l'ouverture d'un fichier par l'appel système `open(2)`_. répertoire - à compléter + Branche de l'arborescence du système de fichiers. Un répertoire contient un ou plusieurs fichiers. répertoire courant - à compléter + Répertoire dans lequel l'appel système `open(2)`_ cherchera à ouvrir les fichiers do offset pointer - à compléter + Position de la tête de lecture associée à un fichier ouvert. little endian - à compléter + Ordre dans lequel les octets correspondants à des mots de plusieurs octets sont stockés en mémoire. Voir https://fr.wikipedia.org/wiki/Boutisme#Little_endian big endian - à compléter + Ordre dans lequel les octets correspondants à des mots de plusieurs octets sont stockés en mémoire. Voir https://fr.wikipedia.org/wiki/Boutisme#Little_endian lien symbolique - à compléter + Unix supporte deux types de liens. Les liens durs créés par `ln(1)`_ et les liens symboliques créés par `ln(1)`_ avec l'argument ``-s``. appel système lent - à compléter + Un appel système lent est un appel système qui peut attendre un temps indéfini pour se terminer. Par exemple, l'appel `read(2)`_ sur l'entrée standard ne retournera de résultat que lorsque l'utilisateur aura pressé une touche sur le clavier. SSD @@ -399,13 +399,81 @@ Glossaire Système de stockage de données s'appuyant uniquement sur de la mémoire flash. root - à compléter + Racine de l'arborescence des fichiers mais aussi utilisateur ayant les privilèges les plus élevés sur un ordinateur utilisant Unix. userid - à compléter - + Identifiant d'utilisateur. Sous Unix, un entier unique est associé à chaque utilisateur. + Unicode Norme d'encodage de caractères supportant l'ensemble des langues écrites, voir notamment https://en.wikipedia.org/wiki/Unicode raspberry pi Systèmes informatiques développés par la Raspberry Pi Foundation, voir https://www.raspberrypi.org + + +.. spelling:: + + proc + Tanenbaum + Programming + Aqua + endian + overflow + Complex + cpp + deadlock + debugger + dynamic + eip + multithreadé + Foundation + garbage + is + not + libc + Torvalds + little + endian + liveness + llvm + livelock + Amdahl + Inc + Makefile + memory + leak + multitasking + multithreadé + nibble + pid + Access + Memory + raspberry + Reduced + root + scheduler + fault + shared + library + Solaris + Sun + Microsystems + Solid + static + library + stderr + stdin + stdout + safety + safe + lab + userid + Pentium + Centrino + Xeon + von + Neumann + makefile + coeurs + Labs + Editeur diff --git a/Theorie/intro.rst b/Theorie/intro.rst index 3abc5b3c78b919f3fddeddf5c4fcd67ce5ccc065..66712b5bee234563f83a9e1fe6eb5016d286249e 100644 --- a/Theorie/intro.rst +++ b/Theorie/intro.rst @@ -69,7 +69,11 @@ Possédant les mêmes composants que décrits ci-dessus, ils fonctionnent de la Labs Amsterdam d'Amsterdam + raspberry + pi + nano + Unix ---- @@ -117,7 +121,11 @@ Unix s'appuie sur la notion de processus. Une application est composée de un ou Dans le cadre de ce cours, nous aurons l'occasion de voir en détails de nombreuses librairies d'un système Unix et verrons le fonctionnement d'appels systèmes qui permettent aux logiciels d'interagir directement avec le noyau. Le système Unix étant majoritairement écrit en langage C, ce langage est le langage de choix pour de nombreuses applications. Nous le verrons donc en détails. -Pour vous permettre de mettre vos apprentissages en pratique, vous recevrez durant le quadrimestre un raspberry pi. Il est possible d'installer différents systèmes d'exploitation sur celui-ci. Nous utiliserons raspbian qui est lui aussi une variante de Unix. +Pour vous permettre de mettre vos apprentissages en pratique, vous recevrez durant le quadrimestre un `raspberry pi <https://www.raspberrypi.org/>`_. Il est possible d'installer différents systèmes d'exploitation sur celui-ci. Nous utiliserons `raspbian <https://www.raspberrypi.org/downloads/raspbian/>`_ qui est lui aussi une variante de Unix. + +.. spelling:: + + raspbian Utilitaires ^^^^^^^^^^^ diff --git a/Vagrantfile b/Vagrantfile index 7f99fbadc165c62c9f7a7392e98e86bc0f9e81df..d1d82482ffbc20e0de0e50bf17f11e8afa2942d1 100644 --- a/Vagrantfile +++ b/Vagrantfile @@ -73,6 +73,7 @@ Vagrant.configure(2) do |config| sudo apt-get install -y texlive-latex-extra sudo apt-get install -y texlive-fonts-recommended sudo apt-get install -y python-sphinxcontrib.spelling + sudo apt-get install -y hunspell hunspell-fr SHELL # sudo apt-get install -y python-setuptools # sudo apt-get install -y mscgen