CHIR Rennes (2004) Bétourné

article en cours d'installation

Titre

Ésope : une étape de la recherche française en systèmes d'exploitation (1968-1972)

Auteurs

Claude Bétournéⁱ, Jean Ferriéⁱⁱ, Claude Kaiserⁱⁱⁱ, Sacha Krakowiak^iv et Jacques Mossière^v.

Affiliations

• i - 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 9^ème 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 [26], 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 [19] au MIT, précurseur de Multics [20] en cours de développement ; Genie [39] à 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 [22]).

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 [7]. 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 [44]).

Contexte institutionnel et naissance du projet

Le 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.

1. 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.
2. Nous associer à un autre projet développant un système d'exploitation sur la 10070. Un tel projet, appelé SAM [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.
3. 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 [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 [46] pour SAM, lp10070 [8] pour Ésope) et les contacts s'arrêtèrent là.

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.
• 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. 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 [44] 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 [17] de la compagnie américaine Scientific Data Systems (SDS), 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, 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,
• 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 [12], [13].

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 [14].

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.

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 [25], nos références dans ce domaine ont été les travaux de Saltzer au MIT [48] et de Lampson à Berkeley [38], 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 [27], [35] 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 1.3 (note 2), 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.

Analyse critique

La CII 10070 de l'IRIA (vers 1973)
De gauche à droite : Kaiser, Lemaire, Saltel, X. . ., Boulenger (devant la console graphique), Gros

Références

[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.

[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.

[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.

[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.

[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.

[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.

[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].

[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.

[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.

[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.

[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.

[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].

[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.

[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.

[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].

[16] ↑ C. Bétourné and S. Krakowiak. Mesures sur un système conversationnel. Revue RAIRO-Informatique, B-2 : 5{15, juillet 1975.

[17] ↑ Keith G. Calkins. The Computer That Will Not Die : The SDS Sigma 7, 1984.
http ://www.andrews.edu/~calkins/profess/SDSigma7.htm.

[18] ↑ R. Chevance. Le projet Y. In Quatrième Colloque sur l'histoire de l'informatique, Rennes, novembre 1995.
http ://www.feb-patrimoine.com/histoire/english/projet y.pdf.

[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.

[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.

[21] ↑ Corna�on (nom collectif). Systèmes informatiques répartis { concepts et techniques. Dunod, 1981.

[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.
http ://cnum.cnam.fr/RUB/histcrocus.pdf.

[23] ↑ Peter J. Denning. Thrashing : Its Causes and Prevention. In Proceedings of the AFIPS Fall Joint Computer Conference, pages 915{922, 1968.

[24] ↑ Jack B. Dennis. Segmentation and the Design of Multiprogrammed Computer Systems. Journal of the ACM, 12(4) : 589{602, October 1965.

[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]
http ://www.cs.utexas.edu/users/EWD/ewd01xx/EWD123.PDF.

[26] ↑ E. W. Dijkstra. The Structure of the "THE" Multiprogramming System. Communications of the ACM, 11(5) : 341{346, May 1968.

[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.

[28] ↑ P. Freeman. Software Systems Principles : A Survey. Science Research Associates, 1975. cité pp. 541, 631.

[29] ↑ E. Gelenbe and C. Kaiser, editors. Operating Systems : Proceedings of an International Symposium, volume 16 of LNCS, IRIA, Rocquencourt, April 1974. Springer Verlag.

[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.

[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.

[32] ↑ A. N. Habermann. Introduction to Operating System Design. Science Research Associates, 1976. 372 pp., cit�e pp. 84{85.

[33] ↑ C. Kaiser and S. Krakowiak. Analyse de quelques pannes d'un syst�eme d'exploitation. In Gelenbe and Kaiser [29], pages 188{207.

[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.

[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.

[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.

[37] ↑ C. J. Kuehner and B. Randell. Demand Paging in Perspective. In Proceedings of the AFIPS Fall Joint Computer Conference, pages 1011{1017, 1968.

[38] ↑ B. W. Lampson. A Scheduling Philosophy for Multi-processing Systems. Communications of the ACM, 11(5) : 347{359, May 1968.

[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.

[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.

[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.

[42] ↑ Stuart E. Madnick and John J. Donovan. Operating Systems. McGraw-Hill, 1974. 640 pp., cit�e p.:574.

[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.

[44] ↑↑ 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].

[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.

[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.

[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.

[48] ↑ J. H. Saltzer. Tra�c Control in a Multiplexed Computer System. Ph.D. thesis, MIT, July 1966. Tech. Report MAC-TR-30.

[49] ↑ Alan C. Shaw. The Logical Design of Operating Systems. Prentice Hall, 1974. 304 pp., cit�e p. 80.

[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.

[51] ↑ A. J. Shils. The load leveler. Technical Report RC 2233, IBM T. J.Watson Research Center, October 1968.

[52] ↑ Laurent Trilling and Jean-Pierre Verjus. An Attempted De�nition of an Extensible System. ALGOL 68 Implementation, pages 119{139, 1970.

[53] ↑ Gerald M. Weinberg. The Psychology of Computer Programming. Van Nostrand Reinhold, 1971.

[54] ↑ H. Whit�eld and A. S. Wight. EMAS : Edinburgh Multi-Access System. The Computer Journal, 4 : 331{346, 1974.

[55] ↑ Niklaus Wirth. PL360, a Programming Language for the 360 Computers. Journal of the ACM, 15(1) : 37{74, 1968.