Protocol based programming of concurrent systems

Tese de mestrado, Engenharia Informática (Engenharia de Software), Universidade de Lisboa, Faculdade de Ciências, 2014Desenvolver sistemas de software concorrentes (e paralelos) seguros é difícil. É muito mais difícil verificar software paralelo do que é fazer o mesmo para aplicações sequenciais. A Message Passing Interface (MPI) é uma especificação independente de linguagem para protocolos de comunicação, utilizada para programar computadores paralelos e baseada no paradigma de troca de mensagens, seguindo o paradigma Single Program Multiple Data (SMPD) em que um único pedaço de código é partilhado por todos os processos. Programas MPI apresentam uma séria de desafios de correção: o tipo de dados trocados na comunicação pode não corresponder, o que resulta em computações erradas, ou o programa pode entrar numa situação de impasse resultando em recursos desperdiçados. Este trabalho tem como objective melhorar o estado-da-arte da verificação de programas paralelos. O estado-da-arte na verificação de programas MPI utiliza técnicas de verificação de modelos que não escalam com o número de processos e são tipicamente feitas em tempo de execução, o que desperdiça recursos e está dependente da qualidade do conjunto de testes. A nossa abordagem é inspirada em tipos de sessão multi-participante (multi-party session types). A teoria dos tipos de sessão parte da caracterização da comunicação entre vários processos de um programa de um ponto de vista global (mensagem do processo 0 para o processo 1 corresponderia a envio para o processo 1 no processo 0 e recebo do processo 0 no processo 1 localmente). A esta caracterização dá-se o nome de protocolo. Protocolos bem formados são por construção livres de impasse e a comunicação é correcta (o tipo de dados enviado é o mesmo que o tipo de dados recebido). Se for provado que um programa segue um protocolo, então essas mesmas propriedades (ausência de impasses e correcção na comunicação) são preservadas para o programa. Primeiro, um protocolo é especificado numa linguagem desenhada para o efeito. As primitivas suportadas pela linguagem de protocolos são baseadas nas primitivas MPI, com a adição de escolhas e ciclos colectivos. Estas primitivas representam tomadas de decisão colectivas que não recorrerem a comunicação. Tomadas de decisão colectivas acontecem em programas SPMD porque todos os processos partilham o mesmo código, e como tal é possível garantir que todos os programas calculam o mesmo valor num certo ponto do programa se os dados forem iguais. Além disso, foi adicionada uma primitiva foreach, que expande um pedaço de protocolo para uma gama de valores. Esta primitiva permite que protocolos sejam paramétricos quanto ao número de processos. Os dados enviados nas mensagens podem ter restrições associadas, especificadas recorrendo a tipos dependentes. Os protocolos são escritos num plugin Eclipse. O plugin valida a boa formação dos protocolos com base numa teoria, utilizando o SMT solver Z3 da Microsoft Research para provar certas propriedades, e que as restrições nos tipos dependentes são congruentes. O plugin foi implementado recorrendo a Xtext, uma framework para desenvolvimentos de plugins Eclipse. O plugin, além de validar a boa formação, compila os protocolos para vários formatos, entre os quais o formato Why. Why é uma das linguagens da plataforma Why3, uma plataforma para verificação dedutiva de software. A linguagem Why é utilizada para escrever teorias, e é aliada à linguagem WhyML (inspirada em OCaml) para escrita de programas. Foi desenvolvida em Why uma teoria para protocolos, em que protocolos são especificados como um tipo de dados da linguagem. O ficheiro gerado pelo plugin especifica um protocolo utilizando os construtores deste tipo de dados Para especificar as restrições de tipos dependentes, uma teoria de funções anónimas incluída com a plataforma Why3 é utilizada. Além disso, foi desenvolvida uma biblioteca WhyML para programação paralela. Esta biblioteca inclui primitivas inspiradas em MPI, e primitivas para escolhas colectivas e ciclos colectivos. Estas primitivas têm como pré-condição que a cabeça do protocolo é a primitiva esperada, e que os dados a serem enviados respeitam a restrição do tipo de dados a ser enviado. Todas as primitivas têm como parâmetro o estado actual do protocolo, e na sua pós-condição consomem a primitiva à cabeça. Graças a estas anotações é possível saber se o programa segue o protocolo, confirmando no final do programa se o protocolo foi consumido por completo. Dado um programa paralelo escrito em WhyML, o protocolo em formato Why e a teoria de protocolos, o programador pode utilizar o Why3 IDE para verificar a conformidade do programa face ao protocolo. O Why3 IDE permite dividir a prova em partes, e provar cada parte com um SMT solver diferente. Caso nenhum SMT solver seja capaz de provar uma das sub-provas, o programador pode recorrer a um proof assistant e tratar da sub-prova manualmente. Além das anotações de primitivas colectivas, o programador também precisa de por um anotação no final de cada bloco que verifica se o protocolo está vazio naquele ponto (sem a qual não é possível garantir que o protocolo foi seguido), de marcar que partes do código correspondem a que expansão da primitiva foreach, e precisa de adicionar variantes e invariantes aos ciclos. Em resumo, a nossa abordagem é a seguinte: 1. O programador escreve um protocolo que explicita globalmente a comunicação que deve ocorrer.2. Este protocolo, se bem formado, é correcto por construção. A comunicação é correcta e é livre de impasses.3. A boa formação do protocolo é feita num plugin Eclipse, que também o compila para vários formatos, entre os quais o formato Why. 4. O programador escreve o seu programa paralelo em WhyML, recorrendo a uma biblioteca de programação paralela inspirada em MPI desenvolvida neste projecto. 5. As primitivas da biblioteca são anotadas com pré e pós-condições que verificam a conformidade do programa face ao protocolo. 6. Oprograma, aliado ao protocolo em formato Why e a uma teoria de protocolos, é verificado no Why3 IDE 7. O Why3 IDE permite dividir a prova em partes, e provar cada parte com um SMT solver diferente. No caso em que nenhum SMT solver consiga tratar da sub-prova, o programador pode recorrer a um proof assistant e tratar da sub-prova manualmente. 8. Se o programa passar na verificação, as propriedades do protocolo (correcção na comunicação e ausência de empasses) são garantidas para o programa. Estas anotações impõe trabalho extra ao programador, mas são dentro do esperado para este tipo de ferramenta. A nossa solução foi testada com recurso a três programas MPI, obtidos em livros de texto. Foram verificados vários exemplos clássicos de programação paralela, adaptados de livros de texto. Comparativamente à ferramenta mais próxima (que utiliza o verificador de programas C, VCC), o número de anotações da nossa solução é menor, as anotações enquadram-se melhor com o código e o tempo de verificação é semelhante. No entanto, a nossa solução recorre a uma linguagem que não é apropriada para a industria, a linguagem WhyML. As linguagens C ou Fortran aliadas à biblioteca MPI são o gold standard para programação paralela de alta performance, e são as linguagens com que os programadores no ramo estão familiarizados. Como tal, para trabalho futuro, propomos o desenvolvimento de uma linguagem de alto nível o mais semelhante possível a C ou Fortran, com primitivas de programação paralela built-in, incluindo escolhas colectivas e ciclos colectivos. Esta linguagem deverá compilar para código C ou Fortran, convertendo as primitivas da linguagem em primitivas MPI. Este passo de conversão pode também optimizar o programa, recorrendo a primitivas de comunicação MPI mais eficientes que as usadas, sendo esta uma funcionalidade importante para programação paralela de alta performance cuja principal preocupação é a eficiência do programa. Compilando também para WhyML, estes programas podem ser verificados. E como as primitivas de programação paralela são built-in na linguagem, a grande maioria das anotações necessárias pode ser gerada automaticamente. É também necessário suportar mais funcionalidades MPI, incluindo comunicação assíncrona, topologias e comunicadores.Developing safe, concurrent (and parallel) software systems is hard. It is much more difficult to debug or verify parallel software than it is to do the same for sequential applications. The Message Passing Interface (MPI) [12] is a languageindependent specification for communication protocols, used to program parallel computers and based on the message-passing paradigm. MPI programs present a number of correctness challenges: communication may not match, resulting in errant computations, or the program may deadlock resulting in wasted resources. This work hopes to improve the state-of-the-art of MPI program verification. The state-of-the-art in MPI program verification relies on model-checking techniques which do not scale with the number of processes and are typically done at runtime, which wastes resources and is dependent on the quality of the test set. Our approach is inspired by multi-party session types. First, a protocol is specified in a language designed for the purpose. A well-formed protocol is communication-safe and deadlock free. An Eclipse plugin verifies the well-formation of the protocol, and compiles it to Why, a language of a deductive software verification platform called Why3. This compiled protocol, allied with a theory for protocols also written in Why, is used to verify parallel WhyML programs, WhyML being another language of the Why3 platform. If a program passes verification, the properties of communication safety and deadlock freedom are preserved for the program. This verification occurs at compile time and is not dependent on any kind of test set, avoiding the issues of model-checking techniques. We verified several parallel programs from textbooks using our approach

Jahresbericht 2008 zur kooperativen DV-Versorgung

:VORWORT 9 ÜBERSICHT DER INSERENTEN 10 TEIL I ZUR ARBEIT DER DV KOMMISSION 15 MITGLIEDER DER DV KOMMISSION 15 ZUR ARBEIT DES LENKUNGSAUSSCHUSSES FÜR DAS ZIH 17 ZUR ARBEIT DES WISSENSCHAFTLICHEN BEIRATES DES ZIH 18 TEIL II 1 DAS ZENTRUM FÜR INFORMATIONSDIENSTE UND HOCHLEISTUNGSRECHNEN (ZIH) 21 1.1 AUFGABEN 21 1.2 ZAHLEN UND FAKTEN (REPRÄSENTATIVE AUSWAHL) 21 1.3 HAUSHALT 22 1.4 STRUKTUR / PERSONAL 23 1.5 STANDORT 24 1.6 GREMIENARBEIT 25 2 KOMMUNIKATIONSINFRASTRUKTUR 27 2.1 NUTZUNGSÜBERSICHT NETZDIENSTE 27 2.1.1 WiN IP Verkehr 27 2.2 NETZWERKINFRASTRUKTUR 27 2.2.1 Allgemeine Versorgungsstruktur 27 2.2.2 Netzebenen 27 2.2.3 Backbone und lokale Vernetzung 28 2.2.4 Druck Kopierer Netz 32 2.2.5 Funk LAN (WLAN) 32 2.2.6 Datennetz zwischen den Universitätsstandorten und Außenanbindung 33 2.2.7 Datennetz zu den Wohnheimstandorten 38 2.3 KOMMUNIKATIONS UND INFORMATIONSDIENSTE 39 2.3.1 Electronic Mail 39 2.3.1.1 Einheitliche E-Mail-Adressen an der TU Dresden 42 2.3.1.2 Struktur- bzw. funktionsbezogene E-Mail-Adressen an der TU Dresden 42 2.3.1.3 ZIH verwaltete Nutzer-Mailboxen 43 2.3.1.4 Web-Mail 43 2.3.1.5 Neuer Mailinglisten-Server 43 2.3.2 WWW 44 2.3.3 Authentifizierung und Autorisierung (AAI) 46 2.3.3.1 Shibboleth 47 2.3.4 Wählzugänge 47 2.3.5 Time Service 47 3 ZENTRALE DIENSTANGEBOTE UND SERVER 49 3.1 BENUTZERBERATUNG (BB) 49 3.2 TROUBLE TICKET SYSTEM (TTS) 50 3.3 NUTZER MANAGEMENT 51 3.4 LOGIN SERVICE 53 3.5 BEREITSTELLUNG VON VIRTUELLEN SERVERN 53 3.6 STORAGE MANAGEMENT 54 3.6.1 Backup Service 54 3.6.2 File Service und Speichersysteme 56 3.7 LIZENZ SERVICE 57 3.8 PERIPHERIE SERVICE 57 3.9 PC POOLS 57 3.10 SECURITY 59 3.10.1 IT Sicherheit 59 3.10.2 DFN PKI 59 3.10.3 VPN 59 3.10.4 Konzept der zentral bereitgestellten virtuellen Firewalls 59 4 SERVICELEISTUNGEN FÜR DEZENTRALE DV SYSTEME 61 4.1 ALLGEMEINES 61 4.2 PC SUPPORT 61 4.2.1 Investberatung 61 4.2.2 Implementierung 61 4.2.3 Instandhaltung 61 4.3 MICROSOFT WINDOWS SUPPORT 62 4.4 ZENTRALE SOFTWARE BESCHAFFUNG FÜR DIE TU DRESDEN 71 4.4.1 Arbeitsgruppentätigkeit 71 4.4.2 Strategie des Software Einsatzes an der TU Dresden 71 4.4.3 Software Beschaffung 72 5 HOCHLEISTUNGSRECHNEN 73 5.1 HOCHLEISTUNGSRECHNER/SPEICHERKOMPLEX (HRSK) 73 5.1.1 HRSK Core Router 74 5.1.2 HRSK SGI Altix 4700 74 5.1.3 HRSK PetaByte Bandarchiv 76 5.1.4 HRSK Linux Networx PC Farm 77 5.1.5 HRSK Linux Networx PC Cluster (HRSK Stufe 1a) 79 5.2 NUTZUNGSÜBERSICHT DER HPC SERVER 79 5.3 SPEZIALRESSOURCEN 80 5.3.1 SGI Origin 3800 80 5.3.2 NEC SX 6 81 5.3.3 Anwendercluster 82 5.4 GRID RESSOURCEN 82 5.5 ANWENDUNGSSOFTWARE 84 5.6 VISUALISIERUNG 84 5.7 PERFORMANCE TOOLS 86 6 WISSENSCHAFTLICHE KOOPERATION, PROJEKTE 87 6.1 „KOMPETENZZENTRUM FÜR VIDEOKONFERENZDIENSTE“ 87 6.1.1 Überblick 87 6.1.2 Umbau der Räume des VCC 87 6.1.3 Aufgaben und Entwicklungsarbeiten 87 6.1.4 Weitere Aktivitäten 89 6.1.5 Der Dienst „DFNVideoConference“ Mehrpunktkonferenzen im G WiN 90 6.1.6 Tendenzen und Ausblicke 91 6.2 D GRID 92 6.2.1 Hochenergiephysik Community Grid (HEP CG) - Entwicklung von Anwendungen und Komponenten zur Datenauswertung in der Hochenergiephysik in einer nationalen e Science Umgebung 92 6.2.2 MediGRID - Ressourcefusion für Medizin und Lebenswissenschaften 92 6.2.3 D Grid Integrationsprojekt 93 6.2.4 Chemomentum 93 6.3 BIOLOGIE 94 6.3.1 Entwicklung eines SME freundlichen Zuchtprogramms für Korallen 94 6.3.2 Entwicklung und Analyse von stochastischen interagierenden Vielteilchen Modellen für biologische Zellinteraktion 94 6.3.3 Verbundsystem EndoSys: Modellierung der Rolle von Rab Domänen bei Endozytose und Signalverarbeitung in Hepatocyten 95 6.3.4 ZebraSim: Modellierung und Simulation der Muskelgewebsbildung bei Zebrafischen 95 6.3.5 Ladenburger Kolleg BioLogistik: Vom bio inspirierten Engineering komplexer logistischer Systeme bis zur „NanoLogistik“ 96 6.3.6 Räumlich zeitliche Dynamik in der Systembiologie 96 6.4 PERFORMANCE EVALUIERUNG 97 6.4.1 SFB 609: Elektromagnetische Strömungsbeeinflussung in Metallurgie, Kristallzüchtung und Elektrochemie Teilprojekt A1: Numerische Modellierung turbulenter MFD Strömungen 97 6.4.2 BenchIT: Performance Measurement for Scientific Applications 97 6.4.3 Parallel Programming for Multi core Architectures − ParMA 98 6.4.4 VI HPS: Virtuelles Institut − HPS 99 6.4.5 Paralleles Kopplungs Framework und moderne Zeitintegrationsverfahren für detaillierte Wolkenprozesse in atmosphärischen Modellen 99 6.4.6 Virtuelle Entwicklung von Keramik und Kompositwerkstoffen mit maßge schneiderten Transporteigenschaften 100 6.4.7 Designing self organized adaptive services for open source internet telephony over p2p networks 100 7 AUSBILDUNGSBETRIEB UND PRAKTIKA 103 7.1 AUSBILDUNG ZUM FACHINFORMATIKER / FACHRICHTUNG ANWENDUNGSENTWICKLUNG 103 7.2 PRAKTIKA 104 8 AUS UND WEITERBILDUNGSVERANSTALTUNGEN 105 9 VERANSTALTUNGEN 107 10 PUBLIKATIONEN 109 TEIL III BERICHTE DER ZENTRALEN EINRICHTUNGEN BIOTECHNOLOGISCHES ZENTRUM (BIOTEC) 115 BOTANISCHER GARTEN 119 LEHRZENTRUM SPRACHEN UND KULTURRÄUME (LSK) 121 MEDIENZENTRUM (MZ) 125 UNIVERSITÄTSARCHIV 135 BERICHT DER ZENTRALEN UNIVERSITÄTSVERWALTUNG 137 BERICHT DES MEDIZINISCHEN RECHENZENTRUMS DES UNIVERSITÄTSKLINIKUMS CARL GUSTAV CARUS 139 SÄCHSISCHE LANDESBIBLIOTHEK − STAATS UND UNIVERSITÄTSBIBLIOTHEK DRESDEN 14

Runtime MPI Correctness Checking with a Scalable Tools Infrastructure

Increasing computational demand of simulations motivates the use of parallel computing systems. At the same time, this parallelism poses challenges to application developers. The Message Passing Interface (MPI) is a de-facto standard for distributed memory programming in high performance computing. However, its use also enables complex parallel programing errors such as races, communication errors, and deadlocks. Automatic tools can assist application developers in the detection and removal of such errors. This thesis considers tools that detect such errors during an application run and advances them towards a combination of both precise checks (neither false positives nor false negatives) and scalability. This includes novel hierarchical checks that provide scalability, as well as a formal basis for a distributed deadlock detection approach. At the same time, the development of parallel runtime tools is challenging and time consuming, especially if scalability and portability are key design goals. Current tool development projects often create similar tool components, while component reuse remains low. To provide a perspective towards more efficient tool development, which simplifies scalable implementations, component reuse, and tool integration, this thesis proposes an abstraction for a parallel tools infrastructure along with a prototype implementation. This abstraction overcomes the use of multiple interfaces for different types of tool functionality, which limit flexible component reuse. Thus, this thesis advances runtime error detection tools and uses their redesign and their increased scalability requirements to apply and evaluate a novel tool infrastructure abstraction. The new abstraction ultimately allows developers to focus on their tool functionality, rather than on developing or integrating common tool components. The use of such an abstraction in wide ranges of parallel runtime tool development projects could greatly increase component reuse. Thus, decreasing tool development time and cost. An application study with up to 16,384 application processes demonstrates the applicability of both the proposed runtime correctness concepts and of the proposed tools infrastructure