Static Validation of Barriers and Worksharing Constructs in OpenMP Applications

International audienceThe OpenMP specification requires that all threads in a team execute the same sequence of worksharing and barrier regions. An improper use of such directive may lead to deadlocks. In this paper we propose a static analysis to ensure this property is verified. The well-defined semantic of OpenMP programs makes compiler analysis more effective. We propose a new compile-time method to identify in OpenMP codes the potential improper uses of barriers and work-sharing constructs, and the execution paths that are responsible for these issues. We implemented our method in a GCC compiler plugin and show the small im-pact of our analysis on performance for NAS-OMP benchmarks and a test case for a production industrial code

A Functional Safety OpenMP∗ for Critical Real-Time Embedded Systems

OpenMP* has recently gained attention in the embedded domain by virtue of the augmentations implemented in the last specification. Yet, the language has a minimal impact in the embedded real-time domain mostly due to the lack of reliability and resiliency mechanisms. As a result, functional safety properties cannot be guaranteed. This paper analyses in detail the latest specification to determine whether and how the compliant OpenMP implementations can guarantee functional safety. Given the conclusions drawn from the analysis, the paper describes a set of modifications to the specification, and a set of requirements for compiler and runtime systems to qualify for safety critical environments. Through the proposed solution, OpenMP can be used in critical real-time embedded systems without compromising functional safety.This work was funded by the EU project P-SOCRATES (FP7-ICT-2013- 10) and the Spanish Ministry of Science and Innovation under contract TIN2015- 65316-P.Peer ReviewedPostprint (author's final draft

A toolchain to verify the parallelization of OmpSs-2 applications

Programming models for task-based parallelization based on compile-time directives are very effective at uncovering the parallelism available in HPC applications. Despite that, the process of correctly annotating complex applications is error-prone and may hinder the general adoption of these models. In this paper, we target the OmpSs-2 programming model and present a novel toolchain able to detect parallelization errors coming from non-compliant OmpSs-2 applications. Our toolchain verifies the compliance with the OmpSs-2 programming model using local task analysis to deal with each task separately, and structural induction to extend the analysis to the whole program. To improve the effectiveness of our tools, we also introduce some ad-hoc verification annotations, which can be used manually or automatically to disable the analysis of specific code regions. Experiments run on a sample of representative kernels and applications show that our toolchain can be successfully used to verify the parallelization of complex real-world applications.This project is supported by the European Union’s Horizon 2021 research and innovation programme under grant agreement No 754304 (DEEP-EST), by the European Union’s Horizon 2020 research and innovation programme under grant agreement No 871669 (AMPERE) and the Project HPCEUROPA3 (INFRAIA-2016-1-730897), by the Ministry of Economy of Spain through the Severo Ochoa Center of Excellence Program (SEV-2015-0493), by the Spanish Ministry of Science and Innovation (contract TIN2015-65316-P), and by the Generalitat de Catalunya (2017-SGR-1481).Peer ReviewedPostprint (author's final draft

OpenMP tasking model for Ada: safety and correctness

22nd International Conference on Reliable Software Technologies (Ada-Europe 2017). 12 to 16, Jun, 2017. Vienna, Austria.The safety-critical real-time embedded domain increasingly demands the use of parallel architectures to fulfill performance requirements. Such architectures require the use of parallel programming models to exploit the underlying parallelism. This paper evaluates the applicability of using OpenMP, a widespread parallel programming model, with Ada, a language widely used in the safety-critical domain. Concretely, this paper shows that applying the OpenMP tasking model to exploit fine-grained parallelism within Ada tasks does not impact on programs safeness and correctness, which is vital in the environments where Ada is mostly used. Moreover, we compare the OpenMP tasking model with the proposal of Ada extensions to define parallel blocks, parallel loops and reductions. Overall, we conclude that the OpenMP tasking model can be safely used in such environments, being a promising approach to exploit fine-grain parallelism in Ada tasks, and we identify the issues which still need to be further researched.info:eu-repo/semantics/publishedVersio

Analysis of an OpenMP Program for Race Detection

The race condition in a shared memory parallel program is subtle and harder to find than in a sequential program. The race conditions cause non-deterministic and unexpected results from the program. It should be avoided in the parallel region of OpenMP programs. The proposed OpenMP Race Avoidance Tool statically analyzes the parallel region. It gives alerts regarding possible data races in that parallel region. The proposed tool has the capability to analyze the basic frequently occurring non-nested ‘for loop(s)’. We are comparing the results of the proposed tool with the commercially available static analysis tool named Intel Parallel Lint and the dynamic analysis tool named Intel Thread Checker for race detection in OpenMP program. The proposed tool detects race conditions in the ‘critical’ region that have not been detected by existing analysis tools. The proposed tool also detects the race conditions for the ‘atomic’, ‘parallel’, ‘master’, ‘single’ and ‘barrier’ constructs. The OpenMP beginner programmers can use this tool to understand how to create a shared-memory parallel program

Static verification of data races in openMP

Tese de mestrado em Engenharia Informática (Engenharia de Software), Universidade de Lisboa, Faculdade de Ciências, 2014Com o uso de linguagens paralelas nascem alguns problemas como data race , uma argura para os programadores durante o seu trabalho. Data race são quando dois ou mais threads em um único processo acedem a mesma posic¸ ão de memória ao mesmo tempo, sendo que um ou mais acessos são para a escrita/leitura, sem sincronização adequada. A nossa ferramenta (SVDR: Static Verification of Data race in OpenMP) foi desenvolvida com o propósito de verificar a ausência de data races em OpenMP (uma linguagem de programac¸ ão paralela). Empregamos a verificação estática com intençãoo de encontrar data races sem necessariamente executar o programa, possibilitando dessa forma ao utilizador, encontrar o problema antes de receber o resultado do mesmo. Para melhor compreensão de como funciona a ferramenta, é pertinente apresentar de forma concisa, as linguagens de programac¸ ˜ao aqui abordadas: OpenMP e Boogie. OpenMP (Aberto Multi-Processing) 2.1 ´e um API usado na programação (C, Fortran, C++) em multiprocessadores com memória partilhada em multiplataformas e funciona em quase todos Sistemas operativos e arquitecturas. Boogie [2, 17] ´e uma linguagem de verificação intermédia, projectada como uma camada sobre a qual é possível construir outros verificadores para outras línguaguens. Uma vez aclaradas as definições, é mais fácil contextualizar e compreender como a ferramenta funciona. Como já foi referido previamente, o objectivo da ferramenta é traduzir código OpenMP em código Boogie com o propósito de verificar se existe ou não data race no ficheiro de entrada. Assim sendo, é possível aferir que existem duas etapas para o processo de verificação: a primeira é a tradução de OpenMP em Boogie, e a segunda é a verificação de data race no ficheiro de entrada - que é do tipo bpl, ou seja, código Boogie. A primeira fase não é tratado pela ferramenta, de modo que é necessária uma tradução manual do código OpenMP para o código Boogie. A segunda fase é a ferramenta que foi implementada, SVDR. O SVDR funciona da seguinte forma: recebe como entrada um ficheiro bpl (um OpenMP traduzido em código Boogie) e retorna como resultado um ficheiro bpl com o algoritmo necessário para verificar se há ou não um data race no ficheiro de entrada. O algoritmo criado é baseado no uso de não determinismo, invariantes e assertions. Este funciona do seguinte modo, para verificar a existência de data race num ciclo While, o que se faz é guardar numa variável global, que designamos de current off, o valor actual do índice do array (independentemente de se tratar de uma leitura ou uma escrita, o processo é o mesmo), e atribuir a outra variável global, que denominamos de current,o valor de true. Após guardados os referidos valores, o que se faz a seguir, é a incrementação do ciclo, atribuímos os valores do current e do current off a duas novas variáveis globais previous e previous off. Estas atribuições são feitas para evitar que se aceda duas vezes seguidas a mesma posição, porque isso poderia conduzir a data race. Tanto as atribuições de current como de previous, são feitas dentro de if não determinísticos. Não determinismo é por definição “Uma propriedade da computação na qual pode ter um ou mais resultados”, mas neste caso especifico significa que não é possível saber se entra ou não no if. A razão para o seu uso, é apenas a não necessidade, neste caso, de se guardar todos os valores do currrent, e mudar todos os valores do previous (até porque se tivermos em consideração todas as possibilidade de execução do programa, haverá sempre uma para cada tarefa). Depois de guardados os valores é necessário validá-los de alguma forma, até porque senão, seriam apenas if num programa, ou seja, não teriam nenhum efeito especifico. A modo utilizado para verificar, é empregando assercoes, ou seja, criamos um assert na qual se afirma que caso o previous seja verdadeiro, então o previous off será sempre diferente do índex actual do vector. Caso isto seja verdade, ou seja, caso se ocorra no programa a veracidade dessa afirmação, então não existem data race, caso contrário, existem. Mas para que esse assert seja sempre verdade, durante o programa, é indispensável a criação de uma invariant para suportar a sua veracidade. No nosso caso, as invariantes são testadas usando Houdini 2.2. São criadas bases de invariantes pela ferramenta, que posteriormente ao realizar-se a verificação do ficheiro com o algoritmo no Verificador Boogie, adiciona um atributo relativo ao Houdini. Por fim, para saber se existe ou não data race no código, utilizamos o Verificador Boogie para atestar o programa com o algoritmo. Como conclusão, o que se pode dizer é que a ferramenta apresentou resultados bastante satisfatórios, e que em todos os exemplos apresentados e testados, o efeito foi o esperado. Apesar de algumas limitações, a ferramenta cumpre com o que foi descrito anteriormente Verifica estaticamente a existência de data race na linguagem OpenMP.Increasingly, programmers use multi-core processors to develop code with multiple threads, i.e, parallel programs. There are some tools that support parallelism such as Intel Parallel Lint 2.4.1 or Intel Thread checker 2.4.2 and some parallel programming languages such as OpenMP 2.1. With the use of parallel languages emerged some problems such as data races that no programmer likes to come across when working. Data races are when two or more threads in a single process access the same memory location concurrently and one or more of the accesses are for writing without proper synchronization. Our tool (SVDR: Static Verification of Data race in OpenMP) was developed with the intention to verify data race freedom in OpenMP (a parallel programming language). We used static verification because we wanted to try to find data races without running the program because that way the user discovers the problem before getting results from the program. The SVDR tool works as follows: it receives as input a bpl file (a file with the translated OpenMP code into Boogie code), then the tool performs executes the algorithm on the input, and gives as output the execution, i.e, the Boogie code with the algorithm necessary to verify if there is or not a data race. Next the output of the SVDR is going to be used as input in the Boogie Verifier that will determine whether or not there exists a data race in the input. If there is a data race then the verifier will give an error, otherwise the verifier will verifies the code without any problem. After several tests it was possible for us to verify that the tool works correctly in all tests that we ran. The examples that we ran were with nested loops, but just one of them was parallel, and also with simple loops, with reads and writes, and all of the examples were verified as expected by the Boogie Verifier. The tool is useful to help the user to verify is exists any data race problem in code so that they can solve the problem if it exists

Analyse statique/dynamique pour la validation et l'amélioration des applications parallèles multi-modèles

Supercomputing plays an important role in several innovative fields, speeding up prototyping or validating scientific theories. However, supercomputers are evolving rapidly with now millions of processing units, posing the questions of their programmability. Despite the emergence of more widespread and functional parallel programming models, developing correct and effective parallel applications still remains a complex task. Although debugging solutions have emerged to address this issue, they often come with restrictions. However programming model evolutions stress the requirement for a convenient validation tool able to handle hybrid applications. Indeed as current scientific applications mainly rely on the Message Passing Interface (MPI) parallel programming model, new hardwares designed for Exascale with higher node-level parallelism clearly advocate for an MPI+X solutions with X a thread-based model such as OpenMP. But integrating two different programming models inside the same application can be error-prone leading to complex bugs - mostly detected unfortunately at runtime. In an MPI+X program not only the correctness of MPI should be ensured but also its interactions with the multi-threaded model, for example identical MPI collective operations cannot be performed by multiple nonsynchronized threads. This thesis aims at developing a combination of static and dynamic analysis to enable an early verification of hybrid HPC applications. The first pass statically verifies the thread level required by an MPI+OpenMP application and outlines execution paths leading to potential deadlocks. Thanks to this analysis, the code is selectively instrumented, displaying an error and synchronously interrupting all processes if the actual scheduling leads to a deadlock situation.L’utilisation du parallélisme des architectures actuelles dans le domaine du calcul hautes performances, oblige à recourir à différents langages parallèles. Ainsi, l’utilisation conjointe de MPI pour le parallélisme gros grain, à mémoire distribuée et OpenMP pour du parallélisme de thread, fait partie des pratiques de développement d’applications pour supercalculateurs. Des erreurs, liées à l’utilisation conjointe de ces langages de parallélisme, sont actuellement difficiles à détecter et cela limite l’écriture de codes, permettant des interactions plus poussées entre ces niveaux de parallélisme. Des outils ont été proposés afin de palier ce problème. Cependant, ces outils sont généralement focalisés sur un type de modèle et permettent une vérification dite statique (à la compilation) ou dynamique (à l’exécution). Pourtant une combinaison statique/- dynamique donnerait des informations plus pertinentes. En effet, le compilateur est en mesure de donner des informations relatives au comportement général du code, indépendamment du jeu d’entrée. C’est par exemple le cas des problèmes liés aux communications collectives du modèle MPI. Cette thèse a pour objectif de développer des analyses statiques/dynamiques permettant la vérification d’une application parallèle mélangeant plusieurs modèles de programmation, afin de diriger les développeurs vers un code parallèle multi-modèles correct et performant. La vérification se fait en deux étapes. Premièrement, de potentielles erreurs sont détectées lors de la phase de compilation. Ensuite, un test au runtime est ajouté pour savoir si le problème va réellement se produire. Grâce à ces analyses combinées, nous renvoyons des messages précis aux utilisateurs et évitons les situations de blocage