Voir la source de CHIR Rennes (2004) Bétourné

{{Wicri travaux|texte=article en cours d'installation}}
;Titre:[[a pour titre::Ésope : une étape de la recherche française en systèmes d'exploitation (1968-1972)]]
;Auteurs:[[a pour premier auteur::Claude Bétourné]]<sup>i</sup>, [[a pour auteur::Jean Ferrié]]<sup>ii</sup>, [[a pour auteur::Claude Kaiser]]<sup>iii</sup>, [[a pour auteur::Sacha Krakowiak]]<sup>iv</sup> et [[a pour auteur::Jacques Mossière]]<sup>v</sup>.
;Affiliations:
* i - [[A pour affiliation auteur::Université Paul Sabatier]], IRIT
* ii - Université des Sciences et Techniques du Languedoc, LIRMM
* iii - Conservatoire National des Arts et Métiers, Cedric
* iv - Université Joseph Fourier, IMAG-LSR et INRIA
* v - Institut National Polytechnique de Grenoble, IMAG-LSR et INRIA
;Résumé:Cet article retrace l'histoire d'Ésope, un projet de système d'exploitation en temps partagé, mené à l'IRIA entre 1968 et 1972. Il présente la place d'Ésope dans le contexte national et international de l'époque, résume et commente les principaux choix qui ont guidé sa conception et sa réalisation, et propose une analyse critique des aspects scientifiques du projet, de sa gestion, et de ses retombées.
;Résumé (anglais):''This paper is a historical account of the Ésope project, an experimental time-sharing system developed at IRIA between 1968 and 1972. The following aspects are presented: the situation of Ésope in the national and international context of the period; a summary and comment of its main design and implementation decisions; and a critical assessment of the scientific and management aspects of the project, and of its follow-ups.
;In:Article publié danns les Actes du [[CHIR 2004 Rennes|9<sup>ème</sup> Colloque sur l'histoire de l'informatique et des télécommunications]] (CHIR 2004), Rennes, 16-18 novembre 2004
==Origines et contexte initial==
Le projet Ésope a été lancé en mi-1968, dans une période marquée par une importante transformation du paysage informatique français et par une intense activité de recherche dans le domaine des systèmes d'exploitation. L'orientation du projet a été influencée par ces deux aspects de son contexte initial, que nous rappelons brièvement avant de développer ses motivations et ses objectifs.
===Contexte scientifique===
La période 1966-68 est une phase cruciale de l'histoire des systèmes d'exploitation. On peut dire qu'en l'espace de 2 ou 3 ans ce domaine passe d'un stade de savoir-faire technique (d'ailleurs fort développé) à celui de discipline scientifique. Pour la première fois, une conférence patronnée par l'ACM s'intitule en 1967 ''Symposium on Operating Systems Principles'' ; ce sera la première édition de la série SOSP, aujourd'hui conférence bisannuelle de grand prestige dont la vingtième édition aura lieu en 2005. Le numéro de mai 1968 des Communications of the ACM reprend les meilleures communications de ce symposium. Il contient entre autres l'article de Dijkstra sur le système THE <span id="ref.26">[[#bib.26|[26]]]</span>, qui aura une influence profonde et durable.

Au cours de ces années auront été élaborés les principes de base de la synchronisation (notion de processus, mécanisme des sémaphores), de l'adressage (segmentation), de la protection (première ébauche des capacités), des systèmes de fichiers hiérarchiques. Les premières mémoires paginées sont apparues, et les déboires des premiers systèmes à mémoire virtuelle avec pagination à la demande (écroulement) commencent à être analysés. On connaît quelques prototypes de recherche : THE, déjà cité, à Eindhoven ; CTSS <span id="ref.19">[[#bib.19|[19]]]</span> au MIT, précurseur de Multics <span id="ref.20">[[#bib.20|[20]]]</span> en cours de développement ; Genie <span id="ref.39">[[#bib.39|[39]]]</span> à Berkeley, bientôt suivi de CAL/TSS, MTS à l'université de Michigan. Le domaine est donc foisonnant, et la mise en forme de ces connaissances nouvelles est elle-même une activité proche de la recherche (voir <span id="ref.22">[[#bib.22|[22]]]</span>).

La conception du système Ésope a été influencée par tous ces travaux. Nous y revenons en détail dans la section 2.

Les systèmes industriels qui vont intégrer certains de ces progrès n'auront en revanche pas d'influence sur Ésope : ils utilisent des architectures trop éloignées du Sigma 7 (notre machine, voir 2.1) comme le Burroughs B5500 ou ne sont pas encore dévoilés en 1968. IBM travaille sur CP/67, encore expérimental, qui introduit les concepts de machine virtuelle et d'hyperviseur, et qui sera le support du très populaire CMS, lui-même ancêtre de VM/370. BBN (Bolt Beranek and Newman Inc.) développe Tenex sur un DEC PDP-10 <span id="ref.7">[[#bib.7|[7]]]</span>. Bull, en France, prépare l'architecture HB 64 et le système GCOS 64 qui s'inspirent de Multics et qui seront annoncés en 1974. Les premiers Unix apparaissent en 1969 aux Bell Labs sur PDP-7 et PDP-9 ; sur PDP-11, Unix est opérationnel en 1971 dans une version va-et-vient (swapping) à la CTSS, mais nous ne devions le découvrir qu'en 1973, après la fin d'Ésope (SOSP 1973, puis CACM <span id="ref.44">[[#bib.44|[44]]]</span>).

===Contexte institutionnel et naissance du projet===

Le [[Plan Calcul|plan calcul]] avait été lancé en fin 1966, avec l'objectif de doter la France des capacités industrielles lui permettant d'être autonome dans le domaine des ordinateurs moyens. Outre son volet industriel, la [[Compagnie Internationale pour l'Informatique]] (CII) issue de la fusion des sociétés CAE et SEA, le plan calcul comportait un volet scientifique, l'Institut de Recherche en Informatique et Automatique (IRIA), qui avait pour mission de développer la recherche, la formation, et la diffusion de la connaissance scientifique et technique dans ses domaines de compétence. Mis en place courant 1967, l'IRIA était organisé en six "Directions de Recherche" largement autonomes. La Direction "Structure et Programmation des Calculateurs", sous la conduite de l'ingénieur en chef du génie maritime Henri Boucher, commençait à recruter ses membres en début 1968.

Le projet initial de la Direction de Recherche était de doter l'IRIA d'un système de calcul interactif (on disait alors "conversationnel") multi-utilisateurs. Il faut se souvenir que ce mode de travail était à l'époque relativement peu développé, et que les terminaux étaient essentiellement des télétypes ; les consoles graphiques étaient une ressource rare, coûteuse, difficile à programmer, et il était prévu que nous en recevions une. Le langage PL/1, considéré à l'époque comme "universel", avait été choisi comme langage unique d'interaction.

La mission étant ainsi fixée, il fallait définir un programme de travail. L'IRIA disposait en mi-1968 d'un ordinateur CAE 90-80, machine de conception ancienne, qui arrivait en bout de course. La machine qui nous était promise, la CII 10070, avait beaucoup plus d'attraits (voir 2.1) ; mais sa date de livraison était incertaine, et éloignée d'au moins un an (elle ne devait arriver en fait que 20 mois plus tard). Son environnement logiciel nous était également inconnu ; nous savions, sans plus de précisions, que la CII travaillait à un système multiprogrammé (mais non en temps partagé), MMP (futur Siris 7).

Les voies d'approche possibles étaient en gros les suivantes.
# Prévoir de construire notre environnement de programmation sur le système développé par la CII. Nous avions peu d'informations techniques sur ce système, la CII ne semblant pas à l'époque soucieuse d'établir avec nous des relations autres que de fournisseur à client.
# Nous associer à un autre projet développant un système d'exploitation sur la 10070. Un tel projet, appelé SAM [[#bib.45|[45]]], était mené au CERA (Centre d' Études et de Recherches en Automatique, dépendant de Sup'Aéro), sous la direction de Jean-Paul Rossiensky et Vincent Tixier, et avec la participation de Jean-Yves Leclerc.
# Développer nous-mêmes, sur la 10070 "nue", le système d'exploitation répondant à nos besoins.

Les voies 1 et 2 avaient l'inconvénient de nous rendre dépendants de partenaires dont les objectifs étaient différents des nôtres, qui avaient leur propre calendrier, et dont la volonté de coopération était à nos yeux loin d'être manifeste. La solution 3 n'était pas sans risques ; après tout, même si les plus anciens d'entre nous avaient une expérience de conception et de réalisation en informatique (calcul scientifique pour Bétourné, systèmes temps réel pour Kaiser, acquisition et traitement de données pour Krakowiak), la conception de systèmes d'exploitation était pour nous un domaine nouveau. Mais cette nouveauté même, surtout dans le contexte scientifique qui a été décrit, et le défi que représentait cette construction ex nihilo, emportèrent vite la décision. L'équipe initiale (alors composée de Bétourné, Boulenger, Kaiser, Krakowiak et Mossière – Ferrié devait nous rejoindre en janvier 1969) présenta en octobre 1968 cette proposition à notre directeur Boucher, qui l'approuva sans réserves. Le projet reçut le nom d' Ésope (Exploitation Simultanée d'un Ordinateur et de ses PEriphériques).

L'appui de notre directeur de recherche nous donnait le feu vert vis-à-vis de la direction de l'IRIA. Il n'en fut pas de même pour la Délégation à l'Informatique (l'organe de pilotage du plan calcul), qui voyait d'un mauvais l l'existence de deux projets sur le même thème (celui du CERA et le nôtre) et nous incita vivement à fusionner. Mais cette vue technocratique des choses ignorait les réalités du terrain (les choix de conception de SAM étant déjà faits, l'intérêt scientifique de la collaboration était pour nous voisin de zéro). Une amorce de collaboration fut néanmoins tentée avec SAM en vue de définir un langage commun d'implémentation, dans la ligne de PL360 [[#bib.55|[55]]], langage d'assemblage évolué muni de constructions syntaxiques de haut niveau. Cette tentative échoua en raison de divergences sur la conception ; chacun des projets définit son propre langage (lp70 [[#bib.46|[46]]] pour SAM, lp10070 [[#bib.8|[8]]] pour Ésope) et les contacts s'arrêtèrent là<ref>Une version de SAM fut développée au centre de recherche de la CII, après le départ de ses concepteurs vers fin 1969 ou début 1970, mais ce travail n'eut pas de suites. Une activité de recherche autour de SAM se poursuivit au CERT à [[Toulouse]], après le transfert de Sup'Aéro dans cette ville</ref>.

Quant aux relations avec la CII, elles ne furent pas celles qui auraient dû résulter du cadre institutionnel du plan calcul. L'une des missions de l'IRIA était en effet d'élaborer les connaissances et le savoir-faire qui devaient aider la CII à développer sa propre compétence. Mais la CII ne semblait pas considérer notre projet comme un interlocuteur valable, et ne lui manifesta qu'un intérêt poli et épisodique. La Délégation à l'Informatique, pour sa part, n'avait qu'une idée vague de ce qu'était un projet de recherche, et semblait s'attendre à ce que nous fournissions un produit clés en main. Nous revenons sur ces aspects dans les sections 3.1, 3.3 et 4.

===Objectifs et priorités du projet===
Le projet avait un double objectif :
* développer un système d'exploitation à l'usage interne de l'IRIA. Ce système devait servir de base à un environnement de programmation interactif et partagé pour 3 classes de travaux : l'utilisation du PL/1 en mode conversationnel sur une vingtaine de terminaux, l'exécution d'un travail de fond (batch), et enfin la supervision de tâches en temps réel<ref name="TR">Ce dernier aspect ne fut en fait jamais développé, faute sans doute d'avoir trouvé un domaine d'application.</ref>.
* mener des recherches sur les principes de conception et de réalisation des systèmes d'exploitation ; avant tout, développer la compétence de l'équipe dans ce domaine : nous partions de quasiment zéro. . .

Il était clairement précisé que le prototype construit avait un caractère expérimental ; il ne s'agissait en aucun cas d'un produit, que nous n'avions d'ailleurs pas les moyens de développer, notre équipe de base comprenant 5 personnes (l'effectif est temporairement monté jusqu'à 7 ou 8). Si cette taille réduite nous a amenés à limiter l'ampleur de la réalisation, elle a eu l'avantage de simplifier les problèmes d'organisation ; l'homogénéité de l'équipe a en outre facilité la participation de chacun aux choix et aux décisions.

Pour la conduite du travail, nous avons donc fixé explicitement ou implicitement des sous-objectifs et des priorités. Certains de ces choix ont été orientés par l'objectif de réalisation, d'autres par l'intérêt scientifique (voire l'effet de mode), d'autres enfin sont dus à notre ignorance.

En particulier, nous manquions d'expérience concrète d'utilisation d'un système d'exploitation interactif et partagé, ce qui nous a conduits à sous-estimer deux aspects :
Nous avons donc concentré notre effort sur les points suivants.
* Problèmes liés au temps partagé, notamment ordonnancement des processus, gestion des terminaux, gestion des t^aches conversationnelles.
* Problèmes liés à l'utilisation de la mémoire virtuelle, à l'époque assez peu explorés.
* Problèmes d'allocation de mémoire, notamment ceux liés à la gestion de mémoire paginée et à la prévention de l'écroulement.
La gestion des fichiers et des entrées-sorties non interactives n'a été abordée que relativement
tard dans le projet.

D'autres aspects importants n'ont pas été pris en compte :
* Administration du système (paramétrage, génération, sécurité, journaux, mesures).
* Portabilité des applications depuis ou vers d'autres systèmes.
* Portabilité du système lui-même. Nous n'avons notamment pas cherché à définir une interface basse indépendante du matériel, ni d'interfaces internes standard.

Ces aspects n'étaient pas strictement nécessaires au fonctionnement d'un prototype expérimental et nous les avons explicitement exclus. Ils étaient par ailleurs, à l'époque, considérés comme marginaux sur le plan de la recherche, situation qui n'a commencé à changer qu'au début des années 1990.

Pour répondre à l'objectif de recherche et de formation, nous avons porté une grande attention à la formulation explicite des choix de conception, et à l'élaboration d'une documentation de conception préalable au codage<ref>L'important délai de livraison de la machine a été à cet égard un facteur bénéfique.</ref>. Chacun des membres de l'équipe devait participer à la conception et au codage ; chacun devait avoir une connaissance à peu près complète de l'ensemble du code ; l'organisation était souple et les sous-groupes redéfinis en fonction des t^aches. Ces principes ont été explicitement formulés au début du projet et ont en fait été à peu près suivis.

La suite de cet article développe trois vues du projet Ésope. La section 2 présente une vue architecturale du projet « achevé », replacée dans le contexte de l'époque. La section 3 présente une vue chronologique du développement d'Ésope. La section 4 conclut par une analyse critique du projet et de ses retombées.

==Concepts et architecture du système Ésope==
Nous présentons dans cette section les principaux choix de conception et de réalisation d'Ésope, en mettant en évidence les sources initiales d'inspiration, et également celles apparues au cours du déroulement du projet. Nous mettons également Ésope en perspective par rapport à deux systèmes :
* Unix, aujourd'hui une référence centrale, bien que ce système soit resté inconnu de nous jusqu'en 1973 <span id="ref.44.1">[[#bib.44|[44]]]</span> et que la pagination à la demande n'y ait été introduite qu'en 1978 avec Unix BSD.
* VAX-VMS de DEC (descendant lointain de Tenex), l'un des meilleurs systèmes d'exploitation des années 1980.
Un projet de système d'exploitation est nécessairement influencé par l'architecture de la machine sous-jacente, qu'il s'agisse d'exploiter au mieux ses capacités ou de s'accommoder de ses limitations. C'est pourquoi nous présentons brièvement les principaux traits de la CII 10070.

===La machine CII 10070===
La 10070 était la machine Sigma 7 <span id="ref.17">[[#bib.17|[17]]]</span> de la compagnie américaine Scientific Data Systems (SDS<ref>En mars 1969, SDS fut absorbée par Xerox, donnant naissance à la compagnie Xerox Data Systems (XDS). Cette première tentative d'entrée de Xerox dans le domaine informatique devait tourner court en 1975.</ref>), initialement distribuée sous licence, puis produite, par la CII. Annoncée en 1966 (et livrée la même année), la Sigma 7 était la première machine à mots de 32 bits succédant à une série de machines à 24 bits, comprenant notamment la SDS 940 (support du projet Genie à Berkeley), explicitement dédiée au temps partagé, mode d'utilisation très nouveau à l'époque. La Sigma 7 était annoncée comme ordinateur universel, pour des applications scientifiques, de gestion, et temps réel.

La Sigma 7 était de fait une excellente machine pour le temps réel, grâce à un système d'interruptions bien conçu, comprenant 237 niveaux hiérarchisés, pouvant individuellement être armés et masqués, ainsi qu'à une horloge temps réel avec comptage programmable. Ses performances étaient bonnes pour l'époque (voir ci-après). Sa vocation « temps partagé » se traduisait par la présence de jeux multiples de registres (jusqu'à 32 jeux) pouvant être permutés lors de la commutation du mot d'état<ref>Ce mécanisme, qui était en option, ne fut en fait pas utilisé par Ésope.</ref>, et par une mémoire virtuelle paginée « plate » (la correspondance entre pages virtuelles et pages physiques étant assurée par des registres topographiques permettant une traduction ecace et une commutation rapide entre espaces virtuels). Néanmoins, ce système d'adressage avait deux limitations importantes.
* L'adresse virtuelle (de mot) avait une taille de 17 bits (256 pages de 512 mots), comme l'adresse physique. De ce fait, la taille de l'espace virtuel était limitée à la taille maximale de la mémoire physique.
* Il n'y avait aucun mécanisme de translation d'adresse (registre de base ou autre). De ce fait, un adressage segmenté ne pouvait être que simulé par un mécanisme logiciel ad hoc.
Ces caractéristiques ont directement influencé la conception de la mémoire virtuelle d' Ésope.

La configuration installée à l'IRIA (voir figure 4 en fin d'article) comportait :
* une mémoire centrale en tores de ferrite de 512 K-octets, de temps de cycle 1s,
* trois disques à têtes fixes de 3 M-octets chacun, avec une durée de rotation de 34 ms par tour et un temps de transfert de 13 ms par page<ref>Une anecdote amusante à ce propos : la vitesse de rotation des disques, donc leur débit, était asservie à la fréquence de l'alimentation électrique ; nous avons donc acheté un convertisseur de fréquence de 50 à 60 Hz pour obtenir les performances annoncées par le constructeur américain.</ref>,
* des périphériques classiques : lecteur de cartes, imprimante et dérouleurs de bandes,
* une mémoire de masse (DIMAS) de 200 M-octets équipée de disques à tête mobile,
* 24 téléimprimeurs SAGEM 8/200 à 20 caractères par seconde,
* une console graphique SINTRA VU-2000.
Un système d'exploitation en temps partagé pour la Sigma 7, UTS, avait été annoncé en 1966. Ce système ne fut en fait disponible qu'en 1971 et n'eut aucune influence sur Ésope.

===Architecture d'ensemble du système===
L'organisation du système repose sur un nombre réduit de concepts, exploités à tous les niveaux de façon à obtenir une architecture claire et uniforme <span id="ref.12">[[#bib.12|[12]]]</span>, <span id="ref.13">[[#bib.13|[13]]]</span>.

Les activités du moniteur et des utilisateurs sont représentées par des processus séquentiels, à l'instar du système THE. On peut distinguer diverses familles de processus, les membres d'une même famille se partageant des données. Dans ce but est introduit le concept d'usager, comme association d'une mémoire virtuelle et d'un ensemble de processus s'exécutant dans cette mémoire. Chaque utilisateur interactif du système est ainsi représenté par un usager. Le partage de code réentrant entre usagers est possible, à travers le système de fichiers. La notion d'usager correspond à celle de processus dans Unix, les processus d' Ésope étant en fait des ''threads''.

Le partage des ressources principales, à savoir mémoire centrale et processeur(s), s'effectue entre usagers et non entre processus, pour des raisons indiquées en 2.5. Le système d'exploitation proprement dit (moniteur), qui assure la gestion des usagers, est un ensemble de processus cycliques, généralement résidant et s'exécutant en mémoire physique. Du point de vue de l'allocation de ressources, l'ensemble de ces processus est considéré comme un usager unique prioritaire sur les autres. La décomposition en processus est dirigée par des considérations d'indépendance logique <span id="ref.14">[[#bib.14|[14]]]</span>.

Un autre choix de base d'Ésope, guidé par des considérations d'uniformité, est celui d'un mécanisme unique de synchronisation entre processus, le sémaphore. En conséquence, tous les événements asynchrones, qu'ils proviennent de la détection d'une condition logique ou d'une interruption, sont traduits par une primitive V qui réveille un processus chargé de traiter  l'événement. Ainsi la figure 1 représente deux processus du moniteur et les événements qui les activent. L'un de ces processus gère le flux des usagers en mémoire et élit un usager pour l'attribution du ou des processeurs ; l'autre exécute les requêtes de transfert entre mémoire et disque.
[[Image:Esope1.png|500px|thumb|center|Fig. 1 — Vue partielle de la coopération entre processus dans Ésope.]]

Une partie des actions du moniteur s'exécute en espace virtuel ; en particulier, chaque usager possède un processus premier, représentant du moniteur, dont le rôle est précisé en 2.3. Les pilotes des entrées-sorties lentes constituent un usager particulier (voir 2.4.3), le pilotage des terminaux étant intégré au programme de gestion de chaque usager.

Indiquons enfin quelques éléments sur la taille du système. Dans sa dernière version, le code source d'Ésope comprenait une quinzaine de modules totalisant 17 500 lignes ; la taille du noyau résidant était de 112 K-octets (56 pages), soit 22% de la mémoire physique ; la partie du système s'exécutant dans l'espace virtuel de chaque usager occupait 38 K-octets (19 pages). Aux normes actuelles, Ésope serait plutôt un nano-noyau. . .

===Gestion et synchronisation des processus===
La notion de processus, en tant qu'activité séquentielle d'exécution d'un programme, était récente à l'époque. Outre l'article fondateur de Dijkstra <span id="ref.25">[[#bib.25|[25]]]</span>, nos références dans ce domaine ont été les travaux de Saltzer au MIT <span id="ref.48">[[#bib.48|[48]]]</span> et de Lampson à Berkeley <span id="ref.38">[[#bib.38|[38]]]</span>, qui avaient construit des noyaux de multiprogrammation et examiné les problèmes d'ordonnancement et la représentation des structures de données.

Le noyau développé dans Ésope <span id="ref.27">[[#bib.27|[27]]]</span>, <span id="ref.35">[[#bib.35|[35]]]</span> fournissait des primitives permettant à un processus de réaliser :
* des actions directes sur un processus, comme créer ou détruire un processus du m?me usager ;
* des interactions indirectes de synchronisation par sémaphores ;
* des actions sur son propre comportement, comme suspendre son exécution (pendant un délai), attendre (une date) ou s'autodétruire ;
* des accès à certaines données du système, aux fichiers et aux segments des processus ou des usagers, en particulier par couplage (voir 2.4.2).

Chaque processus est contrôlé par un pouvoir qui définit ses droits tant sur l'exécution de ces actions que sur l'utilisation des ressources physiques (mode — maître ou esclave — d'utilisation de l'unité centrale, clés de protection c^ablée des pages mémoire, masquage de certaines interruptions, etc.). Pour cela les processus sont divisés en 4 classes, chacune ayant un ensemble d'actions permises :
* les processus du moniteur résidant en mémoire,
* le processus premier de chaque usager qui a deux rôles principaux, la gestion de l'usager, (à ce titre, il a des droits d'accès aux sémaphores du moniteur et peut interrompre ou détruire tous les processus de l'usager), et l'interprétation du langage de commande,
* les traducteurs, fils du processus premier, qui utilisent du code partagé entre usagers,
* les processus d'un usager, créés pour un utilisateur du système, et qui ne peuvent directement interagir qu'avec les processus du même usager (par des noms locaux de sémaphores ou par la mémoire virtuelle partagée).

Le choix des sémaphores comme mécanisme de synchronisation, tant pour les processus du moniteur que pour les processus applicatifs, a conduit à associer deux mécanismes d'accès à une structure de données unique en mémoire. Les processus du moniteur utilisent un numéro interne et un accès direct à l'intérieur du noyau. Les processus utilisateurs connaissent les sémaphores par un nom local à chaque usager et la correspondance de ce nom avec le numéro interne est établie par le noyau à la suite d'un appel système.

Pour simplifier leur gestion, les processus et sémaphores du moniteur sont en nombre fixe alors que les processus et les sémaphores des usagers sont créés et détruits dynamiquement. 

Ce mode de gestion s'est révélé trop figé, en particulier pour permettre la souplesse nécessaire à la génération et à l'extension du système lorsqu'il est devenu complexe. Il aurait sans doute fallu permettre une création dynamique des processus et des sémaphores du système, fournir un système de communication entre usagers par boîtes aux lettres et donner plus de dynamisme à la gestion des droits des processus.

Le mécanisme uniforme de gestion des processus a permis une instrumentation simple du suivi de leur exécution concurrente, en notant dans un tampon circulaire la date et le mot d'état programme d'un processus à chaque commutation (qui ne pouvait être occasionnée que par une opération sur un sémaphore ou par la création ou la fin d'un processus). L'horloge temps réel a été utile pour comptabiliser le temps passé dans chaque processus.

Comme indiqué en [[#Objectifs et priorités du projet|1.3]] (note 2<ref name="TR"/>), l'usager temps réel initialement prévu n'a jamais été développé, mais tous les ingrédients existaient pour le faire : un noyau réentrant permettant une prise en compte rapide des interruptions (les primitives longues étaient interruptibles et découpées en sections accessibles en exclusion mutuelle) ; la gestion par priorité des files de processus et de sémaphores ; le \collage" de pages virtuelles en mémoire physique pour y fixer tout ou partie d'un processus (ces mécanismes furent plus tard présents dans VAX-VMS). Il manquait une interface d'utilisation, c'est-à-dire un jeu de coupleurs vers des capteurs ou actionneurs temps réel.

===Gestion de l'information===
Nous décrivons successivement la gestion des fichiers, la constitution de la mémoire virtuelle par couplage et le système de gestion des entrées-sorties.
====Système de fichiers ====
Pour les raisons indiquées en 1.3, nous n'avons pas porté un effort important sur la conception du système de gestion des fichiers. Nous nous sommes contentés de reprendre, en les simplifiant, les idées développées dans Multics, reprises ensuite dans Unix et qui sont toujours utilisées aujourd'hui. Un fichier d'Ésope est un simple flot d'octets sans structure. Pour permettre le couplage en mémoire virtuelle (voir 2.4.2), il est divisé en blocs (articles) dont la taille est égale à celle d'une page. L'implantation des blocs d'un fichier est contenue dans une table d'implantation du fichier (TIF), jouant un rôle analogue à la table des i-nodes d'Unix.

Un système de catalogues hiérarchiques, limité à deux niveaux<ref>Cette décision paraît aujourd'hui surprenante ; elle s'explique probablement par le fait que (dans un contexte de ressources limitées) l'effort supplémentaire de programmation nécessaire pour construire un système hiérarchique complet ne nous a pas paru prioritaire par rapport aux travaux sur l'allocation de ressources, jugés plus novateurs.</ref>, permet la désignation symbolique des fichiers. Lorsqu'un fichier est ouvert, il est également désigné par un nom interne, entrée dans la table des fichiers ouverts (TFO). Cette entrée contient un pointeur vers la TIF du fichier en mémoire.

Nous n'avons prêté que peu d'attention à la permanence des informations. Toutes les tables et tous les catalogues résidaient en mémoire centrale. A la fin d'une session d'exploitation du système, l'ensemble de la mémoire centrale pouvait être vidé sur bande magnétique ; ce vidage constituait le seul moyen de sauvegarde.

====Mémoire virtuelle et couplage====
Un espace virtuel d'Ésope fournit un moyen de désigner un ensemble de blocs de fichier en y associant des adresses virtuelles. Une opération appelée couplage permet de mettre en correspondance une page avec un bloc de fichier.

Chaque espace virtuel est décrit par une table des pages virtuelles (TPV) qui fournit pour chaque page son adresse en mémoire physique (ou 0 si la page n'est pas en mémoire) et le bloc de fichier auquel elle est couplée (numéro de fichier ouvert et numéro de bloc dans le fichier).

La figure 2 présente l'ensemble des structures de données utilisées pour localiser les différentes pages. La partie a) illustre l'utilisation des espaces virtuels comme fenêtres d'accès à l'espace des fichiers ; la partie b) montre la localisation d'une information désignée par une adresse virtuelle.

Nos sources d'influence étaient là encore Multics et les articles de base sur la segmentation (Dennis <span id="ref.24">[[#bib.24|[24]]]</span>, Arden et al. <span id="ref.2">[[#bib.2|[2]]]</span>), mais aussi un système prototype, Gordo <span id="ref.1">[[#bib.1|[1]]]</span>, réalisé à l'UCLA sur une Sigma 7 et qui utilisait le couplage. Nous avons à l'époque sous-estimé le caractère fondateur de l'article de Dennis et étudié de façon détaillée l'article d'Arden et al., beaucoup plus proche de la réalisation.

Nous avons cherché à pallier l'absence de segmentation dans le 10070 en la simulant par le mécanisme du couplage. Mais les contraintes imposées par un espace virtuel linéaire subsistaient. En particulier, des pages contenant des programmes partagés, donc des adresses virtuelles absolues, devaient être couplées aux mêmes adresses virtuelles pour permettre un partage en mémoire centrale (cas du fichier s1, fig. 2 a).

De façon curieuse, nous n'avons pas songé à permettre le partage de code entre processus d'un même usager. Ce partage était réalisé entre usagers, et cela nous a paru suffisant. Partager le code à l'intérieur d'un usager aurait toutefois amené à imposer des conventions de programmation (accès indirect aux données) ou à modifier la mémoire virtuelle à chaque commutation de processus.


[[Image:Esope2.png|500px|thumb|center|Fig. 2 — Gestion de l'information dans Ésope.]]
====Entrées-sorties====
Les échanges avec les fichiers sur disque sont effectués uniquement, après couplage en mémoire virtuelle, via les mécanismes de gestion de mémoire (cf. 2.5). Le système d'entrées-sorties d'Ésope <span id="ref.3">[[#bib.3|[3]]]</span> ne concerne que les échanges avec les périphériques lents : imprimante et lecteur de cartes.

Un usager particulier, l'usager PTT, reçoit via une boîte aux lettres gérée en producteur-consommateur des demandes d'entrée ou de sortie portant sur un fichier complet. A chaque périphérique sont associés deux processus.
* Le facteur du périphérique est responsable du couplage des différentes pages composant le fichier dans des pages virtuelles qui sont collées en mémoire physique jusqu'à la fin de leur transfert. Ce processus s'exécute en adressage virtuel.
* Le pilote du périphérique assure les transferts entre périphérique et mémoire ; pendant chaque exécution d'une entrée-sortie, le pilote est bloqué sur un sémaphore privé, le déblocage étant effectué par un V exécuté par le traitant de l'interruption d'entrée-sortie. Le pilote s'exécute en adressage physique.
* Le facteur et le pilote se synchronisent également selon le schéma producteur-consommateur.

Relu avec recul, le système d'entrées-sorties d' Ésope reste un joli exercice de programmation de processus parallèles communiquant systématiquement par des boîtes aux lettres gérées selon le schéma producteur-consommateur. Un processus chien de garde permet de détecter des erreurs de périphériques ou des pertes d'interruptions. Des commandes permettent à l'opérateur d'immobiliser un périphérique pour permettre des opérations de maintenance (changement du papier de l'imprimante, par exemple).

===Allocation de ressources===
Nous avons choisi l'usager, plutôt que le processus, comme allocataire des ressources physiques, mémoire et processeur. Ce choix a résulté du souci de traiter globalement l'allocation de ces deux ressources (voir plus loin) ; par ailleurs, si un usager a plusieurs processus, le temps de commutation de la mémoire virtuelle (long par rapport à celui du processeur), est amorti sur l'ensemble de ces processus.

L'unité centrale est donc allouée en tourniquet aux différents usagers et réquisitionnée à l'expiration d'un quantum d'unité centrale. A l'intérieur d'un usager, l'UC est allouée au processus le plus prioritaire, qui devient le processus élu. Le passage de l'unité centrale d'un processus à un autre ne peut avoir lieu qu'en cas de blocage du processus élu ou d'activation d'un processus plus prioritaire du même usager.

Seuls les usagers prêts (ayant au moins un processus activable) sont candidats à l'admission en mémoire centrale, puis à l'exécution de leurs processus. A chaque usager est associée une catégorie, estimation du nombre de pages nécessaires à son exécution ecace. Un usager n'est admis en mémoire que si le système peut lui réserver un nombre de cases égal à sa catégorie. Les catégories sont modifiées dynamiquement en fonction du comportement individuel de chaque usager. La réservation de mémoire est effectuée pour un intervalle de temps maximum appelé temps de résidence. Un usager est également chassé de la mémoire en cas de dépassement de sa catégorie ; il y sera réadmis avec une catégorie supérieure.

Le chargement des pages est effectué à la demande et l'algorithme de remplacement est un algorithme FIFO par usager, imposé par l'absence de bit d'utilisation des pages. Pour diminuer le nombre des transferts de page, plusieurs améliorations ont été implantées (distinction entre pages modifiées et intactes, et récupération des pages en mémoire qui avaient été libérées, mais non encore recopiées sur disque). Pour réduire la durée des transferts en réorganisant l'ordre des demandes pour minimiser le nombre de tours de disque nécessaire, les demandes de pages sont regroupées pour tous les processus d'un usager et sont acquittées globalement.

Enfin, les programmes partagés sont gérés de façon à permettre le partage en mémoire physique de leurs cases. L'économie était substantielle dans la mesure ou nous disposions d'une seule vraie application, le compilateur-interprète cpl/1 qui était exécuté par l'ensemble des usagers.

Une simulation<ref>Le programme de simulation, écrit en Simula, fut exploité en 1970 au Centre de Calcul Scientifique de l'Armement (CCSA), sur un Univac 1108 qui disposait d'un compilateur de ce langage.</ref> de l'allocation de ressources <span id="ref.15">[[#bib.15|[15]]]</span> permit de valider les principaux choix (gestion des usagers, partage, abandon du préchargement dont l'intérêt était marginal).

Ésope est l'un des premiers systèmes à avoir géré globalement la mémoire et l'unité centrale. Sa gestion des ressources a bénéficié des nombreuses publications des années 1968-70 traitant du comportement des programmes en mémoire paginée et de régulation de charge. Les principales inspirations viennent des travaux effectués à IBM (<span id="ref.37">[[#bib.37|[37]]]</span> pour la pagination, [11, 51] pour la régulation de charge), au MIT (Denning et le modèle du working set <span id="ref.23">[[#bib.23|[23]]]</span>) et à Edimbourg (nous avions suivi un cours de Whitfield décrivant le système EMAS|Edinburgh Multi Access System [54, 50] et eu de nombreux échanges avec Shelness, autre membre de ce projet). Les résultats étaient satisfaisants : une quinzaine d'utilisateurs pouvaient travailler simultanément en interprétant des (petits) programmes PL1.

Notons pour conclure que la gestion de ressources du système VAX-VMS <span id="ref.41">[[#bib.41|[41]]]</span> était extrêmement voisine de celle adoptée pour Ésope, ce qui valide nos choix a posteriori.

==Historique du projet==
Nous présentons les étapes les plus marquantes du projet, avant de traiter de deux aspects connexes : les activités externes liées au projet, et ses relations avec la CII.
===Chronologie du projet===
La figure 3 donne une vue synthétique du déroulement du projet, articulée autour des 5 versions successives du système. On y trouve également une vue des projets associés et des activités connexes (voir 3.2).

[[Image:Esope3.png|500px|thumb|center|Fig. 3 — Chronologie du proje Ésope.]]

Une ''version'' correspond à un état supposé stable du système, qui marque une étape de la conception et de la réalisation, et constitue la base d'expérimentation jusqu'à la sortie de la version suivante. Chaque version avait pour but d'intégrer une fonction nouvelle importante, et de rendre dynamiques des aspects définis statiquement dans les versions antérieures. Les grandes lignes du contenu de chaque version sont indiquées dans la table 1. On notera que les versions 4 et 5 intègrent les systèmes interactifs réalisés au-dessus d' Ésope : environnement cpl/1 <span id="ref.6">[[#bib.6|[6]]]</span> et système graphique métavisu <span id="ref.40">[[#bib.40|[40]]]</span>, <span id="ref.9">[[#bib.9|[9]]]</span>.

L'examen de la figure 3 met en évidence les points suivants :
*La longueur de la phase initiale de conception (environ 18 mois). Cette phase (en partie imposée par le délai de livraison de la machine) nous a permis de réaliser une conception globale (les 6 premiers mois environ) puis une préparation détaillée de la mise en vre de chaque partie, documentée dans une dizaine de notes techniques ; la conception du noyau de gestion de processus a été validée par une simulation en PL/1. Notons que la version de l'article <span id="ref.12">[[#bib.12|[12]]]</span> présentée à SOSP en 1969 reposait essentiellement sur le travail de conception.
* Le délai relativement court entre les versions successives. Ce point est certainement une conséquence du précédent, et de l'utilisation du langage LP10070 de préférence au langage d'assemblage (sauf pour quelques parties restreintes du pilote des disques et du programme d'amorçage). Nous n'avons pas noté de problème majeur de développement, bien que nos outils de mise au point aient été rudimentaires.
* L'importance des activités collatérales liées à la formation. Ce point est développé en 3.2.
* La brutalité de l'arrêt du projet. Ce point est développé ci-après.

<center>
{| class="wikitable" align=center width=70%
|-
!version 
!date 
!caractéristiques
|-
|Ésope-1 
|février 1970 
|Décomposition en processus, gestion de 2 usagers interactifs avec mémoires virtuelles préparées \à la main", application minimale (calculette)
|-
|Ésope-2 
|juillet 1970 
|Adressage virtuel, module de gestion du disque, usagers statiquement définis
|-
|Ésope-3 
|octobre 1970 
|Gestion dynamique des processus, allocation de ressources statique, pas de fichiers
|-
|Ésope-4 
|juin 1971 
|Gestion dynamique des ressources, système de fichiers, cpl/1 v. 1
|-
|Ésope-5 
|juin 1972 
|Entrées-sorties, langage de commande, utilitaires divers (chargeur, système de sauvegarde, éditeur de textes), système de mesure, cpl/1 v. 2, système graphique métavisu
|-
|colspan=3|Tab. 1 { Les versions d'Ésope.
|}
</center>

La version Ésope-5 (juin 1972) permettait d'utiliser le langage PL/1 en mode conversationnel sur 16 terminaux avec un temps de réponse acceptable ; cette version servit de support à plusieurs séances de travaux pratiques pour des cours d'analyse numérique. Néanmoins, à partir du début de 1972, la situation du projet était devenue politiquement inconfortable : c'était un projet de recherche (largement reconnu au plan international), mais non évalué comme tel (l'IRIA n'avait aucun processus formel d'évaluation, et les membres du projet aucun statut académique) ; et d'autre part, les responsables de la CII et la Délégation à l'Informatique ne raisonnaient qu'en termes d'utilité immédiate et méconnaissaient le potentiel de compétence et de savoir-faire du projet. Le changement de direction qui eut lieu à l'IRIA en juillet 1972 donna l'occasion de faire un sort à cette activité devenue encombrante en décidant unilatéralement son arrêt. Notre proposition de livrer le système au centre de calcul de l'IRIA pour une utilisation expérimentale ne fut même pas sérieusement examinée.

Après le départ en octobre 1972 de Bétourné et de Mossière, une certaine activité se poursuivit néanmoins pendant un an autour d'Ésope-5. L'utilisation du système pour des séances de TP permit de réaliser quelques mesures <span id="ref.16">[[#bib.16|[16]]]</span>. Un simulateur de charge fut réalisé par Alexandre Brandwajn, qui fit un bref séjour auprès d'Ésope avant de poursuivre des travaux sur la modélisation des systèmes <span id="ref.10">[[#bib.10|[10]]]</span>. Le système servit également de support au travail sur cpl/1 et métavisu. Chaque équipe avait besoin d'espaces d'adressage de grande taille et utilisait le système en stand-alone. Le système fut ainsi utilisé assez longtemps après la dispersion de notre équipe, sans diculté majeure.

===Activités connexes===
Nous avons eu la chance de participer en 1969 à la première École d'été d'informatique CEA-EDF-IRIA, qui avait pour thème les systèmes d'exploitation, et qui nous a permis de fructueuses interactions avec Dijkstra, Randell et Whitfield dans la phase de conception d' Ésope. Nous fûmes ensuite nous-mêmes sollicités pour transmettre notre expérience : d'abord en décembre 1970 pour une formation destinée aux étudiants de DEA et aux chercheurs de Paris-6 ; puis pour un cours à la première École d'été de l'AFCET en juillet 1971. Ce cours fut à l'origine de la création du groupe Crocus <span id="ref.22">[[#bib.22|[22]]]</span> qui devait marquer l'enseignement des systèmes en France pour une dizaine d'années. La première École organisée par Crocus (Les Arcs, mars 1973) fut également la première École de l'IRIA. L'École CEA-EDF-IRIA de 1972 (avec Coffman, Pinkerton et Westcott) fut consacrée aux modèles et mesures de systèmes, thème en phase avec nos préoccupations du moment.

Après la fin du projet, nous avons organisé à l'IRIA en avril 1974 un symposium sur les systèmes d'exploitation <span id="ref.29">[[#bib.29|[29]]]</span>, qui réunit près de 200 personnes avec une très large participation internationale. Le comité de programme, présidé par Arden, comprenait notamment Habermann et Randell.

===Relations avec la CII===

==Analyse critique==
[[Image:CII 10070 IRIA.png|500px|thumb|center|La CII 10070 de l'IRIA (vers 1973)<br/>De gauche à droite : Kaiser, Lemaire, Saltel, X. . ., Boulenger (devant la console graphique), Gros]]

==Références==
:<span id="bib.1">[1]</span> [[#ref.1|'''↑''']] G. B. Anderson, K. R. Bertran, R.W. Conn, K.O. Malmquist, R.E. Millstein, and S. Tokubo. Design of a Time-Sharing System Allowing Interactive Graphics. In Proc. ''ACM National Conference'', pages 1–6, 1968.
:<span id="bib.2">[2]</span> [[#ref.2|'''↑''']] B. W. Arden, B. A. Galler, T. C. O'Brien, and F. H. Westervelt. Program and Addressing Structurein a Time-Sharing Environment. ''Journal of the ACM'', 13(1) : 1–16, January 1966.
:<span id="bib.3">[3]</span> [[#ref.3|'''↑''']] G. Baudet, J. Ferrié, C. Kaiser, and J. Mossière. Entrées-sorties dans un système à mémoire virtuelle. In ''Actes du Congrés AFCET'', Grenoble, novembre 1972.
:<span id="bib.4">[4]</span> [[#ref.4|'''↑''']]Gérard Baudet. ''Étude du comportement d'un tambour soumis à des demandes de transfert groupées''. Thèse de 3-ème cycle, Université Pierre et Marie Curie, Paris-6, 1973.
:<span id="bib.5">[5]</span> [[#ref.5|'''↑''']]Jacques Bellino. ''Mécanismes de base dans les systèmes superviseurs : conception et réalisation d'un système à accés multiples''. Thèse de doctorat ès sciences appliquées, Université de Grenoble, 1973.
:<span id="bib.6">[6]</span> [[#ref.6|'''↑''']] F. Blaizot, L. Blaizot, B. Lorho, and M. Vatoux. Organisation du compilateur interpréteur Cpl/1. In Actes du Congrés AFCET, Paris, avril 1970.
:<span id="bib.7">[7]</span> [[#ref.7|'''↑''']] Daniel G. Bobrow, Jerry D. Burchfiel, Daniel L. Murphy, and Raymond S. Tomlinson. Tenex, a Paged Time Sharing System for the PDP-10. Communications of the ACM, 15(3) : 135{143, March 1972. [Version étendue d'une communication présentée au Third ACM Symposium on Operating Systems Principles, Stanford University (CA, USA), oct. 1971].
:<span id="bib.8">[8]</span> [[#ref.8|'''↑''']] J. Boulenger and M. Kronental. An Experience in System Programming Using a PL360-like Lan:guage. In Proceedings of the IFIP WG-2.4 Meeting, La Grande Motte, May 1974.
:<span id="bib.9">[9]</span> [[#ref.9|'''↑''']] P. Boullier, J. Gros, P. Jancène, A. Lemaire, F. Prusker, and É. Saltel. Métavisu : A General Purpose Graphic System. In IFIP Working Conference on Graphic Languages, Vancouver, Canada, 1972. North-Holland.
:<span id="bib.10">[10]</span> [[#ref.10|'''↑''']] Alexandre Brandwajn. Équivalence et décomposition dans les modèles à files d'attente, et leur application à l'évaluation des performances des systèmes d'exploitation. Thèse de doctorat ès sciences, Université Pierre et Marie Curie, Paris-6, 1975.
:<span id="bib.11">[11]</span> [[#ref.11|'''↑''']] Barbara S. Brawn and Frances G. Gustavson. Program Behavior in a Paging Environment. In Proceedings of the AFIPS Fall Joint Computer Conference, pages 1019{1032, 1968.
:<span id="bib.12">[12]</span> [[#ref.12|'''↑''']] C. Bétourné, J. Boulenger, J. Ferrié, C. Kaiser, S. Krakowiak, and J. Mossière. Process Management and Resource Sharing in the Multiaccess System Esope. Communications of the ACM, 13(12) : 727{733, December 1970. [Version étendue d'une communication présentée au Second ACM Symposium on Operating Systems Principles, Princeton (NJ, USA), oct. 1969].
:<span id="bib.13">[13]</span> [[#ref.13|'''↑''']] C. Bétourné, J. Boulenger, J. Ferrié, C. Kaiser, S. Krakowiak, and J. Mossière. Trois articles : Présentation générale du système Ésope ; Espace virtuel dans le système Ésope ; Allocation de ressources dans le système Ésope. In Actes du Congrés AFCET, avril 1970.
:<span id="bib.14">[14]</span> [[#ref.14|'''↑''']] C. Bétourné, J. Ferrié, C. Kaiser, S. Krakowiak, and J. Mossière. System Design and Implementation using Parallel Processes. In W. H. Freeman, editor, Information Processing, Proceedings of IFIP Congress 71, TA-3, pages 31{36, Ljubljana, August 1971. North-Holland, 1972.
:<span id="bib.15">[15]</span> [[#ref.15|'''↑''']] C. Bétourné and S. Krakowiak. Simulation de l'allocation de ressources dans un système conversationnel à mémoire virtuelle paginée. Revue RAIRO-Informatique, B-1 : 5{10, février 1974. [Version étendue d'une communication présentée au Congrés AFCET, Grenoble, nov. 1972].
:<span id="bib.16">[16]</span> [[#ref.16|'''↑''']] C. Bétourné and S. Krakowiak. Mesures sur un système conversationnel. Revue RAIRO-Informatique, B-2 : 5{15, juillet 1975.
:<span id="bib.17">[17]</span> [[#ref.17|'''↑''']] Keith G. Calkins. The Computer That Will Not Die : The SDS Sigma 7, 1984.<br/>http ://www.andrews.edu/~calkins/profess/SDSigma7.htm.
:<span id="bib.18">[18]</span> [[#ref.18|'''↑''']] R. Chevance. Le projet Y. In Quatrième Colloque sur l'histoire de l'informatique, Rennes, novembre 1995. <br/>http ://www.feb-patrimoine.com/histoire/english/projet y.pdf.
:<span id="bib.19">[19]</span> [[#ref.19|'''↑''']] Fernando J. Corbat�o, Marjorie Merwin-Daggett, and Robert C. Daley. An Experimental Time-Sharing System. In Proceedings of the AFIPS Fall Joint Computer Conference, Part 1, pages 335{344, 1962. Reprinted in Programming Systems and Languages (S. Rosen, ed.), pages 683{698, McGraw-Hill, 1967.
:<span id="bib.20">[20]</span> [[#ref.20|'''↑''']] Fernando J. Corbat�o and Victor A. Vyssotsky. Introduction and Overview of Proceedings of the AFIPS Fall Joint Computer Conference, Part 1, volume 27, pages 185{196, 1965.
:<span id="bib.21">[21]</span> [[#ref.21|'''↑''']] Corna�on (nom collectif). Systèmes informatiques répartis { concepts et techniques. Dunod, 1981.
:<span id="bib.22">[22]</span> [[#ref.22|'''↑''']] Crocus (nom collectif). Crocus, une étape dans l'enseignement des systèmes d'exploitation. In Troisième Colloque sur l'histoire de l'informatique, Sophia Antipolis, octobre 1993.<br/>http ://cnum.cnam.fr/RUB/histcrocus.pdf.
:<span id="bib.23">[23]</span> [[#ref.23|'''↑''']] Peter J. Denning. Thrashing : Its Causes and Prevention. In Proceedings of the AFIPS Fall Joint Computer Conference, pages 915{922, 1968.
:<span id="bib.24">[24]</span> [[#ref.24|'''↑''']] Jack B. Dennis. Segmentation and the Design of Multiprogrammed Computer Systems. Journal of the ACM, 12(4) : 589{602, October 1965.
:<span id="bib.25">[25]</span> [[#ref.25|'''↑''']] E. W. Dijkstra. Cooperating sequential processes. In F. Genuys, editor, Programming Languages : NATO Advanced Study Institute, pages 43{112. Academic Press, 1968. [Initialement publié comme EWD-123, Lecture notes, Eindhoven, 1965]<br/>http ://www.cs.utexas.edu/users/EWD/ewd01xx/EWD123.PDF.
:<span id="bib.26">[26]</span> [[#ref.26|'''↑''']] E. W. Dijkstra. The Structure of the "THE" Multiprogramming System. Communications of the ACM, 11(5) : 341{346, May 1968.
:<span id="bib.27">[27]</span> [[#ref.27|'''↑''']] Jean Ferrié. La gestion des processus dans un système à partage de ressources. Thèse de docteur-ingénieur, Université Paul Sabatier, Toulouse, 1971.
:<span id="bib.28">[28]</span> [[#ref.28|'''↑''']] P. Freeman. Software Systems Principles : A Survey. Science Research Associates, 1975. cité pp. 541, 631.
:<span id="bib.29">[29]</span> [[#ref.29|'''↑''']] E. Gelenbe and C. Kaiser, editors. Operating Systems : Proceedings of an International Symposium, volume 16 of LNCS, IRIA, Rocquencourt, April 1974. Springer Verlag.
:<span id="bib.30">[30]</span> [[#ref.30|'''↑''']] C. Girault. Un des systèmes de multiprogrammation r�ealis�es �a l'Institut de Programmation de la facult�e des sciences de Paris. RIRO, B-2 : 3{18, 1971.
:<span id="bib.31">[31]</span> [[#ref.31|'''↑''']] S. Guiboud-Ribaud and J. Briat. Espace d'adressage et espace d'ex�ecution du système GEMAU. In Gelenbe and Kaiser [29], pages 131{167.
:<span id="bib.32">[32]</span> [[#ref.32|'''↑''']] A. N. Habermann. Introduction to Operating System Design. Science Research Associates, 1976. 372 pp., cit�e pp. 84{85.
:<span id="bib.33">[33]</span> [[#ref.33|'''↑''']] C. Kaiser and S. Krakowiak. Analyse de quelques pannes d'un syst�eme d'exploitation. In Gelenbe and Kaiser [29], pages 188{207.
:<span id="bib.34">[34]</span> [[#ref.34|'''↑''']] C. Kaiser and S. Krakowiak. Design and Implementation of a Time-sharing System : A Critical Appraisal. In J. L. Rosenfeld, editor, Information Processing, Proceedings of IFIP Congress 71, pages 247{251, Stockholm, August 1974. North-Holland.
:<span id="bib.35">[35]</span> [[#ref.35|'''↑''']] Claude Kaiser. Conception et r�ealisation de syst�emes �a acc�es multiple : gestion du parall�elisme. Th�ese de doctorat �es sciences, Universit�e Pierre et Marie Curie, Paris-6, f�evrier 1973.
:<span id="bib.36">[36]</span> [[#ref.36|'''↑''']] Sacha Krakowiak. Conception et r�ealisation de syst�emes �a acc�es multiple : allocation de ressources. Th�ese de doctorat �es sciences, Universit�e Pierre et Marie Curie, Paris-6, f�evrier 1973.
:<span id="bib.37">[37]</span> [[#ref.37|'''↑''']] C. J. Kuehner and B. Randell. Demand Paging in Perspective. In Proceedings of the AFIPS Fall Joint Computer Conference, pages 1011{1017, 1968.
:<span id="bib.38">[38]</span> [[#ref.38|'''↑''']] B. W. Lampson. A Scheduling Philosophy for Multi-processing Systems. Communications of the ACM, 11(5) : 347{359, May 1968.
:<span id="bib.39">[39]</span> [[#ref.39|'''↑''']] B. W. Lampson, W. W. Lichtenberger, and M. W. Pirtle. A User Machine in a Time-sharing System. Proceedings of the IEEE, 54(12) : 1766{1774, December 1966. Reprinted in Computer Structures, ed. Bell and Newell, McGraw-Hill, 1971.
:<span id="bib.40">[40]</span> [[#ref.40|'''↑''']] A. Lemaire and F. Prusker. Principes de fonctionnement et langage de sp�eci�cation des interactions du syst�eme graphique M�etavisu. In Actes du Congr�es AFCET, Grenoble, novembre 1972.
:<span id="bib.41">[41]</span> [[#ref.41|'''↑''']] H. M. Levy and P. H. Lipman. Virtual Memory Management in the VAX/VMS Operating System. IEEE Computer, 15(3) : 35{41, March 1982.
:<span id="bib.42">[42]</span> [[#ref.42|'''↑''']] Stuart E. Madnick and John J. Donovan. Operating Systems. McGraw-Hill, 1974. 640 pp., cit�e p.:574.
:<span id="bib.43">[43]</span> [[#ref.43|'''↑''']] Jacques Mossi�ere. Allocation de ressources dans les syst�emes �a acc�es multiples. Th�ese de 3-�eme cycle, Universit�e Pierre et Marie Curie, Paris-6, juin 1971.
:<span id="bib.44">[44]</span> [[#ref.44|'''↑''']][[#ref.44.1|'''↑''']] Dennis W. Ritchie and Ken Thompson. The UNIX Time-Sharing System. Communications of the ACM, 17(7) : 365{375, July 1974. [Version étendue d'une communication présentée au Fourth ACM Symposium on Operating Systems Principles, Yorktown Heights (NY, USA), oct. 1973].
:<span id="bib.45">[45]</span> [[#ref.45|'''↑''']] Jean-Paul Rossiensky and Vincent Tixier. A Kernel Approach to System Programming : SAM. In J. T. Tou, editor, Software Engineering, volume 1, pages 205{224. Academic Press, New York, 1969.
:<span id="bib.46">[46]</span> [[#ref.46|'''↑''']] Jean-Paul Rossiensky and Vincent Tixier. LP70, a System Programming Language with Parallel Processes. In Proc. International Computing Symposium, pages 492{513, Bonn, Germany, 1970.
:<span id="bib.47">[47]</span> [[#ref.47|'''↑''']] M. Rozier, V. Abrossimov, F. Armand, I. Boule, M. Gien, M. Guillemont, F. Herrmann, C. Kaiser, P. L�eonard, S. Langlois, and W. Neuhauser. The Chorus Distributed Operating System. Computing Systems, 1(4) : 305{379, October 1988.
:<span id="bib.48">[48]</span> [[#ref.48|'''↑''']] J. H. Saltzer. Tra�c Control in a Multiplexed Computer System. Ph.D. thesis, MIT, July 1966. Tech. Report MAC-TR-30.
:<span id="bib.49">[49]</span> [[#ref.49|'''↑''']] Alan C. Shaw. The Logical Design of Operating Systems. Prentice Hall, 1974. 304 pp., cit�e p. 80.
:<span id="bib.50">[50]</span> [[#ref.50|'''↑''']] N. H. Shelness, P. D. Stephens, and H. Whit�eld. The Edinburgh Multi-Access System Scheduling and Allocation Procedures in the Resident Supervisor. In Gelenbe and Kaiser [29], pages 293{310.
:<span id="bib.51">[51]</span> [[#ref.51|'''↑''']] A. J. Shils. The load leveler. Technical Report RC 2233, IBM T. J.Watson Research Center, October 1968.
:<span id="bib.52">[52]</span> [[#ref.52|'''↑''']] Laurent Trilling and Jean-Pierre Verjus. An Attempted De�nition of an Extensible System. ALGOL 68 Implementation, pages 119{139, 1970.
:<span id="bib.53">[53]</span> [[#ref.53|'''↑''']] Gerald M. Weinberg. The Psychology of Computer Programming. Van Nostrand Reinhold, 1971.
:<span id="bib.54">[54]</span> [[#ref.54|'''↑''']] H. Whit�eld and A. S. Wight. EMAS : Edinburgh Multi-Access System. The Computer Journal, 4 : 331{346, 1974.
:<span id="bib.55">[55]</span> [[#ref.55|'''↑''']] Niklaus Wirth. PL360, a Programming Language for the 360 Computers. Journal of the ACM, 15(1) : 37{74, 1968.

==Notes==
<references/>

__SHOWFACTBOX__