The Code of Many Colors: Relating Threads to Code and Shared State
∗
Dean F. Sutherland
Aaron Greenhouse
William L. Scherlis
School of Computer Science, Carnegie Mellon University, Pittsburgh, PA 15213
[email protected],
[email protected],
[email protected]
ABSTRACT
We introduce thread coloring which is designed to support programmer-expressed models that describe precise relationships among code segments, data regions, and threads. For a given thread, the model describes which data regions it may access and which code segments it may execute. For a given data region or code segment, it describes which threads may simultaneously access the data or execute the code. The model allows us to answer questions of non-local character about thread usage policies, including: Which code is intended to be executed by which threads? Which data are possibly shared ? Which data are intended to be thread-local ? Similarly, non-local claims can be verified, for example, Is code executed by only the intended threads? Is thread-locality maintained in the code? The non-local character of these questions and claims means that their answers cannot in general be readily gleaned from code alone. Programmer-expressed color models describe these nonlocal properties in a simple and, we argue, programmerfriendly way. The supporting static analyses are straightforward and composable, requiring only call graph and controlflow graph traversals and algorithms equivalent to reaching definitions and simple type inference. Program annotations are used both to express the model and to link it formally with the code. By treating annotations as cut-points in our analysis, we also support a step-by-step process for recording design intent and establishing assurance. In particular, increments of effort in declaring annotations and carrying out the analyses that relate source code with annotations and policy offer increments of assurance that the code and annotations are consistent. These models are useful for API compliance. In particular, we can verify correct API usage with respect to threads (Section 2) and find API usage bugs (Section 4). We have evaluated this method on a number of case studies from production Java code. We have found a number of subtle concurrency bugs, including a race condition in a widely distributed example applet.
We introduce a thread colors model as a way to express design intent concerning the relationships between threads, executable code, and shared state. By expressing the model as annotations in code, it is possible to formally link the model with source code and to analyze the consistency of model and code in a composable manner. By using annotations as cut-points, APIs can be annotated and compliance with library threading policies can be evaluated. This is illustrated using case study examples from published code that show how thread coloring models can assist in assuring policy compliance and in identifying concurrency errors.
Categories and Subject Descriptors D.1.3 [Programming Techniques]: Concurrent Programming; D.2.1 [Software Engineering]: Requirements/Specifications—Tools, Methodologies; D.2.5 [Software Engineering]: Testing and Debugging
General Terms Design, Reliability
Keywords Java, Race Conditions, Multi-threaded programming, Design Intent
1.
INTRODUCTION
∗
Effort sponsored in part through the High Dependability Computing Program from NASA Ames cooperative agreement NCC-2-1298 and in part by the Defense Advanced Research Projects Agency (DARPA) and Air Force Research Laboratory (AFRL), Air Force Materiel Command, USAF, under agreement number F30602-99-2-0522. The U.S. Government is authorized to reproduce and distribute reprints for Governmental purposes notwithstanding any copyright annotation thereon. The views and conclusions contained herein are those of the authors and should not be interpreted as necessarily representing the official policies or endorsement, either expressed or implied, of NASA, DARPA, AFRL, or the U.S. Government.
1.1
Operational Intuition
A thread model for a program or API centers around explicit programmer-declared color names. A set of colors is associated with every thread. Color names are arbitrary lexical identifiers that have no inherent significance. The programmer may specify an upper bound on the number of threads that may be simultaneously associated with each color. It is an error to exceed this thread count for a color. The following events during the life cycle of a thread affect its set of colors: • A thread comes into existence with an empty color set.
Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, to republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. PASTE’02, November 18–19, 2002, Charleston, SC, USA. Copyright 2002 ACM 1-58113-479-7/02/0011 ...$5.00.
77
/*@ group AWT Thread Usage * color AWT * thread count AWT
