Some resources for teaching concurrency * Ganesh Gopalakrishnan, Yu Yang, Sarvani Vakkalanka, Anh Vo, Sriram Aananthakrishnan, Grzegorz Szubzda, Geof Sawaya, Jason Williams, Subodh Sharma, Michael DeLisi, Simone Atzeni School of Computing, Univ. of Utah, Salt Lake City, UT 84112, USA {ganesh}@cs.utah.edu ABSTRACT With the increasing emphasis on exploiting concurrency ef- ficiently and correctly, the lack of suitable pedagogical ma- terial for teaching concurrency is a growing problem. In this paper, we summarize a recently concluded class as well as some independent projects in the area of concurrency and multi-core computing that offer some insights to address this problem. We examine background papers, the teach- ing of low level concurrency, and the teaching of threading and message passing. The use of dynamic formal verifi- cation tools in a class setting is discussed in some detail. We conclude with a summary of pedagogical material be- ing assembled, including exercises from a popular textbook on MPI solved using our dynamic verifier ISP. Our observa- tion is that the teaching of concurrency is greatly facilitated by the use of dynamic push-button formal verification tools that can handle non-trivial concurrent programs. Given the growing number of publications on how to teach concur- rency as well as employ new programming approaches, our work addresses the somewhat neglected topic of using mod- ern dynamic formal verification methods within the context of widely used concurrency approaches and libraries. Categories and Subject Descriptors D.1.3 [Programming techniques]: Concurrent Program- ming – Threading, Message Passing, Memory Models; K.3.2 [Computers and Education]: Computer science educa- tion – Teaching Concurrency; D.2.4 [Software Engineer- ing]: Formal Methods – Dynamic Verification. General Terms Verification, Concurrency, Education Keywords Multi-core, MPI, Pthreads, Memory Models, Dynamic Ver- * Supported in part by Microsoft, NSF CNS-0509379, CCF- 0811429, and SRC Contract No. 1847.001 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. PADTAD’09, July 19–20, 2009, Chicago, Illinois, USA Copyright 2009 ACM 978-1-60558-656-4/09/07 ...$10.00. ification, Computer Science Education 1. INTRODUCTION The quest to exploit concurrency at all levels – from hard- ware through applications – has made it imperative that fu- ture curricula incorporate concurrency at all levels of the education pipeline. The magnitude of this task is easily ap- preciated if one takes stock of planned hardware/software offerings by the industry, on one hand, and the state of our curricula that is still geared towards sequential program- ming, on the other. It is no surprise that the hardware and software industry has realized the need to close this gap, as evidenced by their various academic programs emphasizing concurrency education (e.g., [1, 2]). This paper summarizes our initial efforts to incorporate concurrency into a graduate level class taught by the first author, with help from his co-authors, It also draws from a few complementary projects aimed at evaluating research tools and available textbooks. As this topic is so diverse, we take the approach of first summarizing how the course and the projects actually evolved. We then summarize some specific resources we would like to offer to the broader com- munity in the form of tools and pedagogical examples. This paper barely scratches the surface of this vast and important topic: the reader is requested to take this paper as the start of a much needed discussion. The tools used in our class were the following: Inspect [46, 47, 48], CHESS [34, 35] (for threading), and ISP [26, 29, 30, 31, 32, 33] for message passing. The choice of Inspect was mainly for the reason that it is the only model checker that can handle large (relatively speaking) concurrent POSIX threading based C programs and verify them using dynamic partial order reduction, yielding significant interleaving re- duction. For a given input test harness, Inspect verifies a program for safety properties including data races, dead- locks, and assertion violations. The choice of ISP was mainly for the reason that it is the only model checker that can handle large MPI C programs. For a given input test har- ness, ISP verifies a program for safety properties including communication races, deadlocks, assertion violations, and resource (e.g., MPI object) leaks. In ISP, we employ our own customized dynamic partial order reduction algorithm called POE [29] that has proved to be indispensable in prac- tice. Also, both Inspect and ISP are developed in our group. ISP is in a fairly polished state, and is being downloaded worldwide [26]. Inspect is also available for downloads. The choice of CHESS was to offer a perspective on how to apply formal methods to .NET applications. We have not explored