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:
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.
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: