Concurrency the First Year

Experience reports panel from SIGCSE 2000

Concurrency as a topic for CS 1 and 2 is at that point in its evolution where early adopters have already obtained several years of experience, but the bulk of educators are still considering their options. Thus we are at the perfect moment for a panel where the early adopters report on their experiences to the broader community of educators considering introducing concurrency in the first year. Each of the panelists has at least three iterations of experience with concurrency in the first year, and will report both on the course design decisions they made and on how those designs have played out. We will then leave thirty minutes for discussion.

Max Hailperin, Gustavus Adolphus College

I will report on six semesters' of experience by my department colleagues and myself. At the end of CS 2 we spend two or three classes and several lab periods giving a taste of concurrency. Our emphasis is on experiencing races and synchronization, and tying this to class invariants. Students really see races happen, and that synchronization matters. They discover that it is very hard to think about concurrent systems, for example to predict symptoms of races. They accept that inductive thinking and invariants may have something to offer.

See also:

David Arnow, Brooklyn College

For the last six years we have consistently struggled to introduce first year students to the concept of concurrent execution. We want our students, in the first year, to understand why concurrency is sometimes necessary or elegant or both; we want them to have experience writing toy concurrent or distributed programs and to experience the advantages that follow; and we want them to witness and have experience in more than one kind of concurrency. However, we defer discussion of synchronization, safety, liveness, termination, lower-level implementation, and interactions with language and library to upper-level courses. Despite our minimal goals, developing a fully satisfactory approach has been a struggle. Switching to Java, however, has resolved all of these problems. We are able to illustrate both shared memory concurrency using Java's threads and distributed programming using Java's I/O facilities.

Judith Bishop, University of Pretoria

We have had four semesters of teaching concurrency as an integral part of CS 1 and 2. We decided to include it in order not to hobble the students in their use of Java. We found that threads are needed even for the simplest animations, and that applets very soon need web access, leading to URL connections. We focus on threads and networking, therefore, and introduce synchronisation for any necessary monitor control.

Our aim in the first year is to show concurrency as a very normal part of life for achieving independent threads of control and multiple copies of active components. We have a suite of well tried examples which start with animation and proceed through to simple monitors. The students extend and adapt these to achieve different effects such as traffic light simulations or simple catch 'em games.

Networking is so streamlined in Java that we could not leave it out. We cover URL connections, sockets and even RMI. For example, when doing a simple program to update an array of people objects towards the end of CS1, students can pull in photographs from all over the world via URLs. Use of sockets leads to chat programs, URL checkers and simple teller machine simulators. Seeing a lab of first years confidently running distributed systems is proof that concurrency in Java is worthy of treatment as a fundamental concept.

See also:

Chester Lund, George Washington University

I performed a controlled experiment by teaching a CS 1 course (using Ada 95) both with and without concurrency. I found that introducing concurrency as a supplemental topic spread over the second half of the semester has little or no adverse effect on the students' learning of sequential concepts. This conclusion is based on statistical results not only from test and project scores, but also from measurements of compiler runs. I will also comment on learning differences I observed in students learning message passing and shared memory concepts.

See also:

Lynn Andrea Stein, Massachusetts Institute of Technology

I have designed a novel CS 1 centered around communities of interacting components; concurrency is integrated throughout. I will report on three semesters of my own experience with this course plus a classroom test at 18 institutions, enrolling over one thousand students. Concurrency is not ``harder'' than traditional (sequential) approaches to computation. It does, however, beget radically different ways of thinking. In fact, I believe that most students come to computer science education with a healthy understanding of how to get along in an inherently concurrent world. My approach to the introductory curriculum is to build on that intuitive understanding. What results is a curriculum in which first-semester students with no prior programming experience learn to build client-server chat programs and networked video games.

See also: