DOCSLIB.ORG

Verteilte Betriebssystemedistributed Operating Systems

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Verteilte Betriebssystemedistributed Operating Systems Verteilte Betriebssysteme – Fallstudien Verteilter Betriebssysteme Verteilte Betriebssysteme 3.1 Motivation Wintersemester 2020/2021 3.1 Motivation I Bevor wir einzelne Aspekte diskutiert, betrachten wir einige reale Betriebssysteme Verteilte Betriebssysteme I Betriebssysteme für verteilte Systeme müssen verschiedene Probleme lösen I Bisher keine einheitliche Problemsicht á unterschiedliche Konzepte und Abstraktionen 3. Kapitel I Sehr heterogen I Noch kaum etablierte best practices oder gar Standards, erst in letzter Zeit Bemühungen im Rahmen Fallstudien Verteilter Betriebssysteme des Cloud-Computing Konzentrieren uns hier auf Abstraktionen Matthias Werner I Professur Betriebssysteme I Unterschiedliche Abstraktionen (Modelle) stellen unterschiedliche Anforderungen an Implementierung WS 2020/21 · Matthias Werner III – 2 von 36 osg.informatik.tu-chemnitz.de Verteilte Betriebssysteme – Fallstudien Verteilter Betriebssysteme Verteilte Betriebssysteme – Fallstudien Verteilter Betriebssysteme 3.2 Mach 3.2 Mach 3.2 Mach – Tore als Stellvertreter Mach-Objekte I Entwickelt 1983–86 von der Carnegie-Mellon-University (CMU) in Pittsburgh I Vorgänger: Accent (1981, CMU) I Ursprüngliches Ziel: Moderne Neuimplementierung von UNIX BSD 4.3 I BS-Kern Mach 3.0 verfügbar für die meisten PC- und Workstation-Prozessoren I Grundlage von OSF/1, dem Unix-Standard der Open System Foundation I Kernel für: I NeXTSTEP / OPENSTEP - Rhapsody I XNU (Basis von Darwin, was wiederum die Basis von MacOS X ist) I MkLinux (Power Macintosh) I GNU Hurd (in Form von GNU Mach) I Tru64 (OSF/1) WS 2020/21 · Matthias Werner III – 3 von 36 osg.informatik.tu-chemnitz.de WS 2020/21 · Matthias Werner III – 4 von 36 osg.informatik.tu-chemnitz.de Verteilte Betriebssysteme – Fallstudien Verteilter Betriebssysteme Verteilte Betriebssysteme – Fallstudien Verteilter Betriebssysteme 3.2 Mach 3.2 Mach Ports Ports (Forts.) I Ports spielen Schlüsselrolle in Mach I Typisch: ein Server verwaltet viele Ports I Ports unterstützen n:1-Kommunikation I Betriebsmittel werden mit Ports identifiziert und ihre Benutzung wird durch eine Nachricht an den I Für jeden Port gibt es zu einem Zeitpunkt genau einen Empfänger (Besitzer des receive rights), aber beliebig zugehörigen Port angefordert viele Sender (Besitzer eines send rights) I Ports bestehen im Wesentlichen aus einer Nachrichtenwarteschlange, deren Größe vom Port-Besitzer Zugriff auf Betriebsmittel wird über Ports geregelt á Recht auf Benutzung eines Betriebsmittels wird über I dynamisch eingestellt werden kann (Flusskontrolle) ein Recht am zugehörigen Port realisiert I Senden an einen vollen Port führt zur Blockierung des sendenden Threads I Die Besitzer der Rechte sind Tasks I Lediglich Sende-Operationen mit send-once right sind auch bei voller Warteschlange erfolgreich I Rechte können in Nachrichten verschickt werden Folgende Rechte sind vorgesehen: I I Existiert kein receive right für einen Port, so werden Sende-Operationen mit einer Fehlermeldung I send right abgewiesen I send-once right I Ebenso kann ein Prozess den Kern beauftragen, ihm mitzuteilen, wenn keine send rights mehr existieren I receive right I bootstrap port right WS 2020/21 · Matthias Werner III – 5 von 36 osg.informatik.tu-chemnitz.de WS 2020/21 · Matthias Werner III – 6 von 36 osg.informatik.tu-chemnitz.de Verteilte Betriebssysteme – Fallstudien Verteilter Betriebssysteme Verteilte Betriebssysteme – Fallstudien Verteilter Betriebssysteme 3.2 Mach 3.2 Mach Ports (Forts.) Entfernte Kommunikation I Mach ist zunächst kein verteiltes System I Der Kern führt Buch über die Zahl I Aber: Das Konzept „Port“ als zentrale Abstraktion macht es leicht, verteilte Betriebssysteme auf der der ausgegebenen Rechte für Grundlage von Mach zu konstruieren einen Port Verwaltung erfolgt im Kernel I I Kommunikation zu anderen Knoten ist Aufgabe einer speziellen Komponente außerhalb des Kerns: Net I Portname (Integer) ist lokal Message Server (NetMsgServer, NMS) bezüglich des Prozesses I NMS-Prozess realisiert die typischen Schichten eines Protokollstapels Kernel isoliert damit I I Er enthält u.a.: Prozesse á Tabellen zur Umsetzung lokaler Portnummern in globale Sicherheitsfeature I I Funktionen zur Wandlung der Datenrepräsentation I Authentisierungsmechanismen I Verschlüsselungsverfahren WS 2020/21 · Matthias Werner III – 7 von 36 osg.informatik.tu-chemnitz.de WS 2020/21 · Matthias Werner III – 8 von 36 osg.informatik.tu-chemnitz.de Verteilte Betriebssysteme – Fallstudien Verteilter Betriebssysteme Verteilte Betriebssysteme – Fallstudien Verteilter Betriebssysteme 3.2 Mach 3.2 Mach Entfernte Kommunikation (Forts.) Arbeiten mit dem NetMsgServer I Dienste registrieren sich beim NetMsgServer netname_look_up() P1 NMS NMS P2 Client NetMsgServer Send receive answer netname_check_in() request Server Netz I NetMsgServer ist auch Dienst. Wie wird er gefunden? á Enviroment-Manager (für lokale Ports) oder Bootstrap-Server (MacOS) mit festem Port WS 2020/21 · Matthias Werner III – 9 von 36 osg.informatik.tu-chemnitz.de WS 2020/21 · Matthias Werner III – 10 von 36 osg.informatik.tu-chemnitz.de Verteilte Betriebssysteme – Fallstudien Verteilter Betriebssysteme Verteilte Betriebssysteme – Fallstudien Verteilter Betriebssysteme 3.2 Mach 3.2 Mach Resümee Andere Mikrokernel-Ansätze I Amoeba I Vrije University/CMCS Amsterdam, 1981 Erkenntnis I Komplettes, Microkernel-basiertes OS mit Prozessor-Pool-Modell, objekt-basiert, verschlüsselte Capabilities I Mikrokernel-Ansatz funktioniert bei verteilten und nichtverteilten Systemen I Prozessmigration I Zentrales Konzept des Ports ermöglicht „Verstecken“ (Transparenz) von Verteiltheit. I gilt als Referenz für verteilte Betriebssysteme I Außerdem interessant bei Mach: I Chorus I Rechteübertragung durch IPC I INRIA (Frankreich), 1979-87, ursprünglich als europäische Konkurrenz zu Mach I Unterstützung verschiedener Modelle zur Speicherverwaltung, insbesondere Paging I Sehr ähnlich zu Mach (konzeptionell), aber kleiner I Copy on write bei neuen Prozessen I MiX: UNIX-Server, COOL: Chorus Object-Oriented Layer I NORMA (No Remote Memory Access Interprocessor Communication) als In-Kernel-Ersatz für I V-System NetMsgServer I Standford University, 1984 I Sehr kleiner Kernel I Möglichkeiten zur Prozessmigration WS 2020/21 · Matthias Werner III – 11 von 36 osg.informatik.tu-chemnitz.de WS 2020/21 · Matthias Werner III – 12 von 36 osg.informatik.tu-chemnitz.de Verteilte Betriebssysteme – Fallstudien Verteilter Betriebssysteme Verteilte Betriebssysteme – Fallstudien Verteilter Betriebssysteme 3.3 Plan 9 3.3 Plan 9 3.3 Plan 9 – Alles ist eine Datei Trivia I Name kommt vom Film Plan 9 From Outer Space I Regie: Ed Wood I Vor dem Hintergrund von UNIX vollständig neu entwickelte Rechenumgebung I gewählt zum schlechtesten Film aller Zeiten I Entwickelt in Computing Science Research Center der Lucent Technologies Bell Laboratories (die gleiche Gruppe, die UNIX, C und C++ entwickelt hat, u.a. ROB PIKE und KEN THOMPSON) I Glenda ist für Plan 9 was Tux für Linux ist: das Maskottchen I Erste Version erschien 1993 (nur im universitären Bereich verfügbar) I Bezieht sich auf einen anderen Ed-Wood-Film: I Offiziell aktuelle Version: Release 4 von 2002 „Glen or Glenda“ I Aber ständige Weiterentwicklung durch die „Community“ (und auch noch etwas durch Bell-Labs) I Letztes Image vom Mai 2016 (Stand: Oktober 2020) I Als Open Source verfügbar, u.a.: http://www.9legacy.org/download.html WS 2020/21 · Matthias Werner III – 13 von 36 osg.informatik.tu-chemnitz.de WS 2020/21 · Matthias Werner III – 14 von 36 osg.informatik.tu-chemnitz.de Verteilte Betriebssysteme – Fallstudien Verteilter Betriebssysteme Verteilte Betriebssysteme – Fallstudien Verteilter Betriebssysteme 3.3 Plan 9 3.3 Plan 9 Design-Ansatz Typische Plan 9 Umgebung Fiber Network I Unix war ursprünglich kein Netzwerk-Betriebssystem á Brüche im Design File server Idee CPU server CPU server Ein UNIX, das aus vielen kleinen Systemen besteht, statt einem System, dass aus vielen UNIXen besteht. Ethernet I Plan 9 I Ein mächtigeres Multiprozess-System I Zentral administrierbar Gateway I Aufwärtskompatibilität war kein Design-Ziel, aber POSIX-Emulation vorhanden Terminal Terminal Terminal WS 2020/21 · Matthias Werner III – 15 von 36 osg.informatik.tu-chemnitz.de WS 2020/21 · Matthias Werner III – 16 von 36 osg.informatik.tu-chemnitz.de Verteilte Betriebssysteme – Fallstudien Verteilter Betriebssysteme Verteilte Betriebssysteme – Fallstudien Verteilter Betriebssysteme 3.3 Plan 9 3.3 Plan 9 Verteilungsabstraktion Beispiele für Dateien I UNIX: zwei zentrale Konzepte: Prozess und Datei I Eigene Shell terminieren ; echo kill > /proc/$pid/ctrl I Plan 9: Alles ist eine Datei: I Gespeicherte Daten und Dateisysteme I Umgebungvariablen auflisten Fenster ; lc /env I '*' cpu init planb sysname I Protokolle 0 cputype location plumbsrv tabstop Netzwerkinterfaces MKFILE disk menuitem prompt terminal I afont ether0 monitor rcname timezone I ... apid facedom mouseport role user Bildschirm-Kopie drucken I Umsetzung der Abstraktion I ; lp /dev/screen I Angepasstes Namensystem notwendig I Jeder Server ist File-Server I DNS-Abfrage I Implementierung mit einer Art NFS-Protokoll: 9P Protokoll (Version 9P2000 auch unter dem Namen ; echo osg.informatik.tu-chemnitz.de!http > /net/dns styx) WS 2020/21 · Matthias Werner III – 17 von 36 osg.informatik.tu-chemnitz.de WS 2020/21 · Matthias Werner III – 18 von 36 osg.informatik.tu-chemnitz.de Verteilte Betriebssysteme – Fallstudien Verteilter Betriebssysteme Verteilte Betriebssysteme – Fallstudien Verteilter Betriebssysteme
Load more

Recommended publications
  • Projeto Integrado Envolvendo a Tecnologia ATM Sobre Um “Backbone”De Alta Velocidade Na Região Metropolitana Do Rio De Janeiro
    Projeto Integrado Envolvendo a Tecnologia ATM sobre um “Backbone”de Alta Velocidade na Região Metropolitana do Rio de Janeiro Instituição Responsável: Universidade Federal do Rio de Janeiro (UFRJ) Coordenação dos Programas de Pós-Graduação em Engenharia (Coppe) Caixa Postal 68.511 - CT, Bloco G - Ilha do Fundão CEP: 21945-970 - Rio de Janeiro, RJ Líder do Projeto: Luís Felipe Magalhães de Moraes CPF: 352.674.617-68 Telefone: (021) 590-2552, r. 306 E-mail: [email protected] 1. SUMÁRIO EXECUTIVO ............................................................................................................ 6 2. DESCRIÇÃO DOS RECURSOS SOLICITADOS (EQUIPAMENTOS, PROGRAMAS E BOLSAS).......................................................................................................................................... 7 2.1 EQUIPAMENTOS CONTIDOS NO ANEXO I DO EDITAL..................................................................... 7 2.2 EQUIPAMENTOS E PROGRAMAS ADICIONAIS POR INSTITUIÇÃO ...................................................... 8 2.3 BOLSAS POR INSTITUIÇÃO.......................................................................................................... 8 2.3.1 CBPF ............................................................................................................................... 8 2.3.2 FioCruz............................................................................................................................ 9 2.3.3 IMPA ..............................................................................................................................
    [Show full text]
  • Architectural Review of Load Balancing Single System Image
    Journal of Computer Science 4 (9): 752-761, 2008 ISSN 1549-3636 © 2008 Science Publications Architectural Review of Load Balancing Single System Image Bestoun S. Ahmed, Khairulmizam Samsudin and Abdul Rahman Ramli Department of Computer and Communication Systems Engineering, University Putra Malaysia, 43400 Serdang, Selangor, Malaysia Abstract: Problem statement: With the growing popularity of clustering application combined with apparent usability, the single system image is in the limelight and actively studied as an alternative solution for computational intensive applications as well as the platform for next evolutionary grid computing era. Approach: Existing researches in this field concentrated on various features of Single System Images like file system and memory management. However, an important design consideration for this environment is load allocation and balancing that is usually handled by an automatic process migration daemon. Literature shows that the design concepts and factors that affect the load balancing feature in an SSI system are not clear. Result: This study will review some of the most popular architecture and algorithms used in load balancing single system image. Various implementations from the past to present will be presented while focusing on the factors that affect the performance of such system. Conclusion: The study showed that although there are some successful open source systems, the wide range of implemented systems investigated that research activity should concentrate on the systems that have already been proposed and proved effectiveness to achieve a high quality load balancing system. Key words: Single system image, NOWs (network of workstations), load balancing algorithm, distributed systems, openMosix, MOSIX INTRODUCTION resources transparently irrespective of where they are available[1].The load balancing single system image Cluster of computers has become an efficient clusters dominate research work in this environment.
    [Show full text]
  • Administration UNIX ARS 2010 – 2011 Partie 1 1 / 822 Chapitre 1 UNIX : Généralités, Historique
    Administration de systèmes UNIX Formation ARS 2010 – 2011 Partie 1 Thierry Besançon Formation Permanente de l’Université Pierre et Marie Curie c T.Besançon (v13.0.486) Administration UNIX ARS 2010 – 2011 Partie 1 1 / 822 Chapitre 1 UNIX : généralités, historique c T.Besançon (v13.0.486) Administration UNIX ARS 2010 – 2011 Partie 1 2 / 822 1 UNIXChapitre : généralités, 1 historique• UNIX : généralités, historique 1.1 UNIX, un système d’exploitation §1.1 • UNIX, un système d’exploitation Un système d’exploitation est une application comme une autre en gros. Par exemple, noyau LINUX version REDHAT 2.6.18-164 : 43682 fichiers dont 18205 fichiers « .c » 17699 fichiers « .h » 1805 fichiers « .S » Les missions d’un système d’exploitation sont : mise à disposition de ressources matérielles : espace disque, temps d’exécution sur le microprocesseur central, espace mémoire, etc. partage équitable de ces ressources entre les utilisateurs pour atteindre le but de système multi-utilisateurs c T.Besançon (v13.0.486) Administration UNIX ARS 2010 – 2011 Partie 1 3 / 822 1 UNIXChapitre : généralités, 1 historique• UNIX : généralités, historique 1.2 Panorama de quelques UNIX du marché §1.2 • Panorama de quelques UNIX du marché Constructeurs de hardware Marque Site web Version d’UNIX APPLE http ://www.apple.com MacOS X 10.x CRAY http ://www.cray.com Unicos ?. ? HP http ://www.hp.com HP-UX 11.x + COMPAQ http ://www.digital.com Tru64 Unix 5.x + DIGITAL IBM http ://www.ibm.com AIX 5.x SGI http ://www.sgi.com IRIX 6.x.y SUN http ://www.sun.com Solaris 10 OpenSolaris 10 Ces UNIX ne sont pas interchangeables : Solaris pour machines de marque SUN MacOS X pour machines de marque APPLE AIX pour machines de marque IBM etc.
    [Show full text]
  • Implementacão De Um Terminal X Para O Sistema Operacional Plurix
    IMPLEMENTACÃO DE UM TERMINAL X PARA O SISTEMA OPERACIONAL PLURIX Luiz Fernado Huet de Bacellar TESE SUBMETIDA AO CORPO DOCENTE DA COORDENAÇÃO DOS PROGRAMAS DE PÓS-GRADUAÇÃO DE ENGENHARIA DA UNIVERSIDADE FEDERAL DO RIO DE JANEIRO COMO PARTE DOS REQUISITOS NECESSARIOS PARA A OBTENÇÃO DO GRAU DE MESTRE EM CIÊNCIAS EM ENGENHARIA DE SISTEMAS E COMPUTAÇÃO. Aprovada por: Prof. Newton Faller, Ph.D. (presidente) RIO DE JANEIRO, RJ - BRASIL MARCO DE 1990 BACELLAR, LUIZ FERNANDO HUET DE Implementação de um Terminal X para o Sistema Operacional Plurix [Rio de Janeiro] 1990 IX, 104 p. 29,7 cm (COPPE/UFRJ, M.Sc., Engenharia de Sistemas e Computação, 1990) Tese - Universidade Federal do Rio de Janeiro, COPPE 1. Sistemas Computacionais Gráficos I. COPPE/UFRJ 11. Título (série). A minha esposa Adriana AGRADECIMENTOS Ao Doutor Newton Faller pelo apoio, incentivo e orientação fornecidos no transcorrer deste trabalho. Aos Doutores Edil severiano Tavares Fernandes e Júlio Salek Aude pela honra de tê-los participando da banca. Aos meus Pais por terem tornado possível a chegada a este ponto. Aos Amigos do NCE que de alguma forma contribuiram para a realização deste trabalho e ao NCE por ter tornado viável o desenvolvimento e a implementação do trabalho. Resumo da Tese apresentada a COPPE/UFRJ como parte dos requisitos necessários para obtenção do grau de Mestre em Ciências (M. Sc. ) IMPLEMENTAÇÃO DE UM TERMINAL X PARA O SISTEMA OPERACIONAL PLURIX Luiz Fernando Huet de Bacellar Março, 1990 Orientador: Prof. Newton Faller, Ph.D. Programa: Engenharia de Sistemas e Computação Este trabalho consiste na definição e implementação de um sistema integrado de hardware e software, denominado Terminal X.
    [Show full text]
  • WORKSHOP PROCEEDINGS First International Workshop on Operating Systems, Programming Environments and Management Tools for High-Performance Computing on Clusters
    First International Workshop on Operating Systems, Programming Environments and Management Tools for High-Performance Computing on Clusters (COSET-1) June 26th, 2004 Saint-Malo, France Ville de Saint-Malo – Service Communication – Photos : Manuel CLAUZIER Held in conjunction with 2004 ACM International Conference on Supercomputing (ICS ’04) WORKSHOP PROCEEDINGS First International Workshop on Operating Systems, Programming Environments and Management Tools for High-Performance Computing on Clusters COSET-1 Clusters are not only the most widely used general high-performance computing platform for scientific computing but also according to recent results on the top500.org site, they have become the most dominant platform for high-performance computing today. While the cluster architecture is attractive with respect to price/performance there still exists a great potential for efficiency improvements at the software level. System software requires improvements to better exploit the cluster hardware resources. Programming environments need to be developed with both the cluster and human programmer efficiency in mind. Administrative processes need refinement both for efficiency and effectiveness when dealing with numerous cluster nodes. The goal of this one-day workshop is to bring together a diverse community of researchers and developers from industry and academia to facilitate the exchange of ideas and to discuss the difficulties and successes in this area. Furthermore, to discuss recent innovative results in the development of cluster based operating systems and programming environments as well as management tools for the administration of high-performance computing clusters. COSET-1 Workshop co-chairs Stephen L. Scott Oak Ridge National Laboratory P. O. Box 2008, Bldg. 5600, MS-6016 Oak Ridge, TN 37831-6016 email: [email protected] Christine A.
    [Show full text]
  • Design of the SPEEDOS Operating System Kernel
    Universität Ulm Fakultät für Informatik Abteilung Rechnerstrukturen Design of the SPEEDOS Operating System Kernel Dissertation zur Erlangung des Doktorgrades Dr. rer. nat. der Fakultät für Informatik der Universität Ulm vorgelegt von Klaus Espenlaub aus Biberach a.d. Riß 2005 Official Copy, serial number df13c6b7-d6ed-e3f4-58b6-8662375a2688 Amtierender Dekan: Prof. Dr. Helmuth Partsch Gutachter: Prof. Dr. J. Leslie Keedy (Universität Ulm) Gutachter: Prof. Dr. Jörg Kaiser (Otto-von-Guericke-Universität, Magdeburg) Gutachter: Prof. John Rosenberg (Deakin University, Geelong, Victoria, Australia) Prüfungstermin: 11.07.2005 iii Abstract (Eine inhaltsgleiche, deutsche Fassung dieser Übersicht ist ab Seite 243 zu finden.) The design of current operating systems and their kernels shows deficiencies in re- spect to the structuring approach and the flexibility of their protection systems. The operating systems and applications suffer under this lack of extensibility and flexib- ility. The protection model implemented in many operating systems is not powerful enough to represent arbitrary protection conditions on a more fine-grained granu- larity than giving read and/or write access to an entire object. Additionally current operating systems are not capable of controlling the flow of information between software units effectively. Confinement conditions cannot be expressed explicitly and thus confinement problems can only be solved indirectly. Further complications with the protection system and especially the software structure in modern operating systems based on the microkernel approach are caused by the use of the out-of-process model. It is extremely difficult to spe- cify access rights appropriately, because the client/server paradigm does not easily allow a relationship to be established between the role of the client and the per- missions of the server.
    [Show full text]
  • Downloaded on 2018-08-23T19:11:32Z Single System Image: a Survey
    View metadata, citation and similar papers at core.ac.uk brought to you by CORE provided by Cork Open Research Archive Title Single system image: A survey Author(s) Healy, Philip D.; Lynn, Theo; Barrett, Enda; Morrisson, John P. Publication date 2016-02-17 Original citation Healy, P., Lynn, T., Barrett, E. and Morrison, J. P. (2016) 'Single system image: A survey', Journal of Parallel and Distributed Computing, 90- 91(Supplement C), pp. 35-51. doi:10.1016/j.jpdc.2016.01.004 Type of publication Article (peer-reviewed) Link to publisher's http://dx.doi.org/10.1016/j.jpdc.2016.01.004 version Access to the full text of the published version may require a subscription. Rights © 2016 Elsevier Inc. This is the preprint version of an article published in its final form in Journal of Parallel and Distributed Computing, available https://doi.org/10.1016/j.jpdc.2016.01.004. This manuscript version is made available under the CC BY-NC-ND 4.0 licence https://creativecommons.org/licenses/by-nc-nd/4.0/ Item downloaded http://hdl.handle.net/10468/4932 from Downloaded on 2018-08-23T19:11:32Z Single System Image: A Survey Philip Healya,b,∗, Theo Lynna,c, Enda Barretta,d, John P. Morrisona,b aIrish Centre for Cloud Computing and Commerce, Dublin City University, Ireland bComputer Science Dept., University College Cork, Ireland cDCU Business School, Dublin City University, Ireland dSoftware Research Institute, Athlone Institute of Technology, Ireland Abstract Single system image is a computing paradigm where a number of distributed computing resources are aggregated and presented via an interface that maintains the illusion of interaction with a single system.
    [Show full text]
  • O Projeto PEGASUS/PLURIX/TROPIX, Um UNIX Brasileiro
    1 O Projeto PEGASUS/PLURIX/TROPIX, um UNIX brasileiro Pedro Salenbauch (editor, autor), Newton Faller (in memoriam), et al. Instituto Tércio Pacitti – NCE Universidade Federal do Rio de Janeiro - UFRJ 1. Introdução AO PLURIX Durante os anos de 1983 a 2012, o NCE/UFRJ desenvolveu o projeto PEGASUS/PLURIX/TROPIX, e este artigo pretende descrever o histórico deste empreendimento. A partir do ano de 1976, diversos pesquisadores do NCE/UFRJ encontravam-se nos Estados Unidos e na Europa em cursos de doutoramento, época em que o Sistema Operacional UNIX começou a ser instalado no computadores das Universidades em que eles se encontravam. O UNIX é um Sistema Operacional desenvolvido nos Laboratórios Bell da AT&T, cuja filosofia, na época revolucionária, influenciou o desenvolvimento de inúmeros Sistemas Operacionais. Durante esta época, inúmeras teses foram desenvolvidas em ambientes UNIX, gerando sistemas específicos para execução em sistemas UNIX. Estes pesquisadores naturalmente tornaram-se apreciadores do Sistema. No entanto, ao retornarem ao Brasil, a partir de 1979, depararam-se com a ausência deste Sistema no Brasil. Foi então tentado, através do NCE/UFRJ o licenciamento do Sistema diretamente da AT&T. As negociações foram iniciadas, mas infelizmente, as respostas da AT&T aos pedidos do NCE/UFRJ foram sempre ambíguas e a decisão final foi sendo sempre adiada e o licenciamento jamais acabou-se concretizando. O motivo foi que o Brasil na época era considerado um país “pirata”, que não respeitava os contratos de licenciamento. Nos anos subsequentes, ainda mais pesquisadores que haviam apreciado o uso do UNIX no exterior retornaram ao Brasil. Com isto, aumentava o número de pesquisadores descontentes, pois no NCE/UFRJ não havia computadores com UNIX, e o que é pior, não havia sequer a perspectiva de tê-los a curto prazo.
    [Show full text]
  • Programming Models and Runtime Systems for Heterogeneous Architectures Sylvain Henry
    Programming Models and Runtime Systems for Heterogeneous Architectures Sylvain Henry To cite this version: Sylvain Henry. Programming Models and Runtime Systems for Heterogeneous Architectures. Other [cs.OH]. Université Sciences et Technologies - Bordeaux I, 2013. English. NNT : 2013BOR14899. tel-00948309 HAL Id: tel-00948309 https://tel.archives-ouvertes.fr/tel-00948309 Submitted on 18 Feb 2014 HAL is a multi-disciplinary open access L’archive ouverte pluridisciplinaire HAL, est archive for the deposit and dissemination of sci- destinée au dépôt et à la diffusion de documents entific research documents, whether they are pub- scientifiques de niveau recherche, publiés ou non, lished or not. The documents may come from émanant des établissements d’enseignement et de teaching and research institutions in France or recherche français ou étrangers, des laboratoires abroad, or from public or private research centers. publics ou privés. Numéro d’ordre: 4899 THÈSE présentée à L’UNIVERSITÉ BORDEAUX 1 ÉCOLE DOCTORALE DE MATHÉMATIQUES ET INFORMATIQUE DE BORDEAUX par Sylvain HENRY POUR OBTENIR LE GRADE DE DOCTEUR SPÉCIALITÉ : INFORMATIQUE *************************************** Modèles de programmation et supports exécutifs pour architectures hétérogènes Programming Models and Runtime Systems for Heterogeneous Architectures *************************************** Soutenue le jeudi 14 novembre 2013 Composition du jury Président : M. Luc Giraud, Directeur de Recherche à Inria Rapporteurs : M. Jean-François Méhaut, Professeur à l’Université de Grenoble M. François Bodin, Professeur à l’Unviersité de Rennes Examinateurs : M. Eric Petit, Ingénieur de Recherche à l’Université de Versailles Saint Quentin (directeur de thèse) M. Denis Barthou, Professeur à l’Institut Polytechnique de Bordeaux (directeur de thèse) M. Alexandre Denis, Chargé de Recherche à Inria Résumé en français Le travail réalisé lors de cette thèse s’inscrit dans le cadre du calcul haute performance sur architectures hétérogènes.
    [Show full text]
  • PLURIX, UNIX E Os Sistemas Abertos
    PLURIX, UNIX e os Sistemas Abertos PLURIX, UNIX e os Sistemas Abertos Newton Faller NCE/UFRJ Tópicos: • Sistemas Abertos • A História do UNIX • Os SOFIX (Sistemas Operacionais com Filosofia UNIX) • Os SOFIX no Brasil • O Desenvolvimento do PLURIX • O Ambiente Operacional de um SOFIX • Desenvolvendo Software num SOFIX • Padrões: SVID, POSIX, X/OPEN • Comunicações: protocolos ISO e TCP/IP • Interfaces Gráficas: X/WINDOW, MOTIF, OPEN LOOK, etc. • Perspectivas PLURIX, UNIX e os Sistemas Abertos SISTEMAS ABERTOS 1) O sistema obedece a especificações bem definidas e disponíveis para a indústria; 2) As especificações são seguidas por produtos de diversos fabricantes de computadores independentes (concorrentes); 3) As especificações não são controladas por um grupo pequeno de fabricantes; 4) As especificações não estão restritas à arquitetura ou tecnologia de um computador específico. Ref.: Pajari, G., "Just what is an Open System", UnixWorld, Nov. 89 PLURIX, UNIX e os Sistemas Abertos HISTÓRIA DO UNIX Final dos anos 60: MULTICS (MIT, BELL, GE) Núcleo Básico: PDP-7 -> PDP-11 Origem da Linguagem C: ALGOL 60 -> BCPL -> B -> C 1973: UNIX reescrito em C abre o caminho para a PORTABILIDADE 1975: Versão 6 -> Universidades 1978: Versão 7 (portátil) -> uso comercial 1982: System III (padrão da AT&T) 1983: System V (novo padrão da AT&T reconhecido pela INTEL, MOTOROLA, NATIONAL e ZILOG) 1984: /usr/group -> Standard Proposal 1985: System V.2 System V Interface Definition (SVID) 1985/1986: X/OPEN (padrão para BULL, ICL, NIXDORF, OLIVETTI, PHILIPS e SIEMENS)
    [Show full text]
  • Parallel Ray-Tracing with a Transactional DSM
    Parallel Ray-Tracing with a Transactional DSM S. Frenz, M. Schoettner, R. Goeckelmann, P. Schulthess Ulm University, Distributed Systems Department [email protected] Abstract Equally important is the automatic consistency management of replicated data in the DSM. Many Distributed Shared Memory (DSM) is a well-known consistency models have been proposed by the DSM alternative to explicit message passing and remote community [3]. Weak and weaker consistency models procedure call. Numerous DSM systems and consistency were introduced and became thus more efficient but also models have been proposed in the past. The Plurix harder to program. Originally, DSM was developed to project implements a DSM operating system (OS) storing allow execution of parallel programs written for data and code within the DSM. Our DSM storage expensive multi-processor machines on cheap commodity features a new consistency model (transactional clusters without major modifications. But using weak consistency) combining restartable transactions with an consistency models required artful modifications to the optimistic synchronization scheme instead of relying on a source code. We believe that this requirement is one of hard to use weak consistency model. In this paper we the reasons why the DSM concept is still not widely evaluate our system for the first time with a real parallel accepted, not even for new application fields. application, a parallel ray-tracer. The measurements Considering this defect the Plurix project implements show that our DSM scales quite well for this application the first OS storing data and code within the DSM. By even though we are using a strong consistency model.
    [Show full text]
  • Fault Tolerance in a DSM Cluster Operating System
    Fault Tolerance in a DSM Cluster Operating System Michael Schoettner, Stefan Frenz, Ralph Goeckelmann, Peter Schulthess Distributed Systems University of Ulm nformatik o-27 89069 Ulm (schoettner)frenz)goeckelmann)schulthess+, informatik.uni-ulm.de Abstract: Pluri. is a new distributed operating system for P0 clusters. 1odes communicate using a Distributed Shared Memory 2DSM3 that stores data and code, including drivers and kernel conte.ts. This approach simplifies global resource management and checkpointing. nstead of e.ecuting processes and threads our operating system uses restartable transactions combined with an optimistic synchronization scheme. 5eyond restartable Transactions the cluster itself is restartable allowing a simple and fast reset of the cluster in case of an non local error. n this paper we describe relevant parts of the Pluri. architecture and discuss how these properties simplify checkpointing and recovery. 6 e also present our current approach for error detection, checkpointing, and recovery. 1 Introduction E.pensive super computers are more and more replaced by cheap commodity P0s clusters. They aggregate resources like 0PU and memory thus enabling the e.ecution of parallel applications. 5ut also the inherent redundancy of hardware and data replication makes clusters interesting for high availability services. mplementing a Single System mage 2SS 3 is a elegant approach to simplify global resource management in a cluster. To avoid mechanism redundancy, conflicting decisions and decrease the software comple.ity, resource management should be organized in a unified and integrated way. 6 e believe it is natural that this is the task of a distributed operating system 28S3. 6 e have developed the Pluri.
    [Show full text]