An Empirical Study of Messaging Passing Concurrency in Go Projects

Go is a popular programming language renowned for its good support for system programming and its channel- based message passing concurrency mechanism. These strengths have made it the language of choice of many platform software such as Docker and Kubernetes. In this paper, we analyse 865 Go projects from GitHub in order to understand how message passing concurrency is used in publicly available code. Our results include the following findings: (1) message passing primitives are used frequently and intensively, (2) concurrency-related features are generally clustered in specific parts of a Go project, (3) most projects use synchronous communication channels over asynchronous ones, and (4) most Go projects use simple concurrent thread topologies, which are however currently unsupported by existing static verification frameworks

Bounded verification of message-passing concurrency in Go using Promela and Spin

This paper describes a static verification framework for the message-passing fragment of the Go programming language. Our framework extracts models that over-approximate the message-passing behaviour of a program. These models, or behavioural types, are encoded in Promela, hence can be efficiently verified with Spin. We improve on previous works by verifying programs that include communication-related parameters that are unknown at compile-time, i.e., programs that spawn a parameterised number of threads or that create channels with a parameterised capacity. These programs are checked via a bounded verification approach with bounds provided by the user

Automated Verification of Go Programs via Bounded Model Checking

The artifact of the ASE 2021 paper entitled "Automated Verification of Go Programs via Bounded Model Checking"

Automatic detection and resolution of deadlocks in Go programs

The Go programming language is acquiring momentum in the development of concurrent software. Even though Go supports the shared-memory model, the message-passing alternative is the favoured idiomatic approach. Naturally, this practice is not exempt of the usual difficulties: programs may deadlock and the language run-time has only very basic support for deadlock detection. Previous research on deadlock detection mainly focused on shared-memory concurrency models. For mainstream languages, tools and approaches specific to the message-passing paradigm are scarce and incipient. There is however a large body of work on models of concurrency that only recently started to be applied to languages like Go. Since the Go run-time lets many deadlocks pass unnoticed, and the existing solutions provided by third party tools detect many deadlocks but only try to fix a limited set of specific patterns, imposing severe conditions to do so, there is a clear need for more general deadlock resolution strategies, going beyond prevention and avoidance. To gain insight on real-world deadlock bugs, we first built and categorized a collection of bugs sourced from high-profile open-source Go projects. Next, we extended and implemented an algorithm that takes an abstraction of the communication behaviour of the program and, when all the communication operations on channels necessary for progress are present, but a deadlock is possible, presents the problem and offers a possible resolution for the error. The extensions allows our approach to analyse a much wider range of real world programs. We conclude with an evaluation, comparing with two other state-of-the-art solutions.A linguagem de programação Go tem ganhado tração no desenvolvimento de software concorrente. Apesar de o Go suportar o modelo de partilha de memória, o modelo alternativo de partilha de mensagens é a abordagem idiomática. Naturalmente, esta prática não está isenta das dificuldades usuais: os programas podem bloquear e o runtime da linguagem só possui um suporte muito básico para a deteção destes bloqueios. Investigação anterior na deteção de bloqueios focou principalmente no modelo de partilha de memória. Para linguagens convencionais, ferramentas e abordagens dedicadas ao paradigma de passagem de mensagens são escassas e incipientes. No entanto, existe um grande conjunto de trabalhos sobre modelos de concorrência que só recentemente começou a ser aplicado em linguagens como o Go. Visto que o run-time do Go deixa muitos bloqueios passar despercebidos e as soluções existentes detetam muitos bloqueios, mas só tentam resolver um conjunto muito pequeno de padrões. De modo a ganhar conhecimento sobre erros de bloqueio reais, nós começámos por construir e categorizar uma coleção de erros obtidos a partir de projetos Go open-source de alto perfil. De seguida, nós estendemos e implementámos um algoritmo que recebe uma abstração do comportamento da comunicação de um programa e quando todas as operações de comunicação nos canais necessários para o progresso estão presentes, mas um bloqueio é possível, apresenta o erro e oferece uma possível resolução do erro. A nossa extensão permite analisar um conjunto muito maior de programas reais. Concluímos com uma avaliação, comparando com duas outras soluções do estado da arte

Towards a Performance Model for Special Purpose ORB Middleware

General purpose middleware has been shown effective in meeting diverse functional requirements for a wide range of distributed systems. Advanced middleware projects have also supported single quality-of-service dimensions such as real-time, fault tolerance, or small memory foot-print. However, there is limited experience supporting multiple quality-of-service dimensions in middleware to meet the needs of special purpose applications. Even though general purpose middleware can cover an entire spectrum of functionality by supporting the union of all features required by each application, this approach breaks down for distributed real-time and embedded sys-tems. For example, the breadth of features supported may interfere with small memory footprint requirements. In this paper, we describe experiments comparing application-level and mechanism-level real-time perfor-\mance of a representative sensor-network application running on three middleware alternatives: (1) a real-time object request broker (ORB) for small-footprint networked embedded sensor nodes, that we have named nORB, (2) TAO, a robust and widely-used general-purpose Real-Time CORBA ORB, and (3) ACE, the low-level middleware framework upon which both nORB and TAO are based. This paper makes two main contributions to the state of the art in customized middleware for distributed real-time and embedded applications. First, we present mechanism-level timing measurements for each of the alternative middleware layers and compare them to the observed performance of the sensor-network application. Second, we provide a preliminary performance model for the observed application timing behavior based on the mechanism-level measurements in each case, and suggest further potential performance optimizations that we plan to study as future work

Automated Verification of Concurrent Go Programs via Bounded Model Checking

The Go programming language offers a wide range of primitives to coordinate lightweight threads, e.g., channels, waitgroups, and mutexes — all of which may cause concurrency bugs. Static checkers that guarantee the absence of bugs are essential to help programmers avoid these costly errors before their code is executed. However existing tools either miss too many bugs or cannot handle large programs, and do not sup- port programs that rely on statically unknown parameters that affect their concurrent structure (e.g., number of threads). To address these limitations, we propose a static checker for Go programs which relies on performing bounded model checking of their concurrent behaviours. In contrast to previous works, our approach deals with large codebases, sup- ports programs that have statically unknown parameters, and is extensible to additional concurrency primitives. Our work includes a detailed presentation of the extraction algorithm from Go programs to models, an algorithm to automatically check programs with statically unknown parameters, and a large scale evaluation of our approach. The latter shows that our approach outperforms the state-of-the-art on 220 synthetic programs and 78 buggy programs adapted from existing codebases

Actor Concurrency Bugs: A Comprehensive Study on Symptoms, Root Causes, API Usages, and Differences

Actor concurrency is becoming increasingly important in the development of real-world software systems. Although actor concurrency may be less susceptible to some multithreaded concurrency bugs, such as low-level data races and deadlocks, it comes with its own bugs that may be different. However, the fundamental characteristics of actor concurrency bugs, including their symptoms, root causes, API usages, examples, and differences when they come from different sources are still largely unknown. Actor software development can significantly benefit from a comprehensive qualitative and quantitative understanding of these characteristics, which is the focus of this work, to foster better API documentations, development practices, testing, debugging, repairing, and verification frameworks. To conduct this study, we take the following major steps. First, we construct a set of 184 real-world Stackoverflow and Github actor bugs by manual analysis of 3,924 Stackoverflow questions, answers, and comments and 3,315 Github commits, messages, original and modified code snippets, issues, and pull requests. Second, we manually study these actor bugs and their fixes to understand and classify their symptoms, root causes, and API usages. Third, we study the differences between the commonalities and distributions of symptoms, root causes, and API usages of Stackoverflow and Github actor bugs. Fourth, we discuss real-world examples of bugs with these root causes and symptoms. Finally, we investigate the relation of our findings with the findings of previous work and discuss the implications of our findings using the anecdotal evidence of our actor bug examples. A few findings of our study are: (1) Symptoms of actor bugs can be classified into 5 categories with Error and Incorrect Exceptions being the most and least common symptoms (2) Root causes of actor bugs can be classified into 10 categories with Logic and Untyped Communication being the most and least common root causes (3) A small number of API packages are responsible for most of API usages by actor bugs (4) Stackoverflow and Github actors can differ significantly in the commonality and distribution of symptoms, root causes, and API usages (5) Actor developers may need help not only with complex, unknown, or semantic bugs in the development code but also with simple, well-known, well-documented, or syntactic bugs in the test code. While some of our findings are in agreement with the findings of the previous work, others are in sharp contrast