to mitigate this issue—if not to ensure
algorithms are correct, at least to get
the students thinking deeply about
correctness and state. I am not expecting
to use such approaches as CSP [ 4], CCS
[ 6] or any of the many available (see [ 3]
for a comprehensive list). Rather, I am
hoping that asking students to provide
state invariants along with method
preconditions and postconditions will
help to minimize the need for a debugger.
Moreover, I suspect they will understand
their code more deeply
At Haverford College, we have
been using a rigorous treatment in our
introductory courses for a few years [ 2].
This approach includes reasoning about
abstract data types using abstraction
functions (i.e., mapping representation
to abstraction), fundamental
constructors (i.e., mapping abstraction to
representation), representation invariants
and even axioms to define methods in the
abstract. It is my intention to revisit this
mathematical reasoning for shared objects
in the current concurrency course. These
reasoning tools are on top of the standard
ones used in CS1, such as preconditions,
postconditions and loop invariants.
One issue in computer science reported
from our students (via course evaluation
surveys and informal conversations) in
CS2 is a lack of notational consistency.
I have been using a functional notation
for most of these reasoning tools, but
the students are asked to apply this to
object-oriented programs, and that seems
to breed confusion. I am considering the
Java Modelling Language (JVM) [ 5], which
is a design by contract language that
might alleviate some of these notational
consistency issues reported in previous
courses. If it works out, then I can see the
JVM introduced earlier in our curriculum.
At this point in the course (i.e.,
approximately three weeks into the
term), I believe I have made the basic
points about the tradeoffs of concurrent
programs. Labs so far have demonstrated
that concurrency, while possible, is not
a panacea (see Figure 1). But so far, the
programs have all been direct to get
correct, so I am looking next for examples
that are more of a challenge. Simulating
social media with users as threads
sounds like an appealing way to engage
students with a more appropriate use of
By the way, there will be two labs
involving software-hardware codesign
using a virtual processor that students
completed in the previous course. The
projects involve implementing a simulated
printer, first using polling, then interrupts.
Concurrency is a topic that is
simultaneously conceptual, and yet still
practical as multicore and distributed
systems have emerged as a popular
platform. More importantly, helping
students prepare for this way of thinking
about expressing algorithms is not only
critical, but rewarding, at least for me.
As a concluding observation (thread?)
in this column, I want to pivot to why
we adapt our courses and improve
our teaching. Recently, I read the story
written by a young woman in the Seattle
area about her experience learning
programming [ 1]. I expected her to discuss
an appreciation of computational thinking
that is often emphasized in K- 12 computing
education. However, I was taken by her
ability to see the importance and relevance
to inclusion, and that an ability to “think
computationally” and express ideas in
code supports diversity. It is a good feeling
when the code works as expected, but
an even better feeling when the student
learns more (or deeper) than expected.
1. Chen, H. Student Voices: Why all kids need to learn
computer science. The Seattle Times (online), 2019;
www.seattletimes.com/education-lab/student-voices-why-all-kids-need-to-learn-computer-science/. Accessed 2019 February 4.
2. Dougherty, J. P., and Wonnacott, D. W. Use and
assessment of a rigorous approach to CS1.
In Proceedings of the 36th SIGCSE Technical
Symposium on Computer Science Education
(SIGCSE ‘05). (ACM, New York, 2005), 251–255.
3. Fontaine, P. Techniques for verification of concurrent
systems with invariants. Doctoral dissertation, PhD
thesis, (Institut Montefiore, Université de Liege,
4. Hoare, C. A. R. A theory of CSP. Commun. ACM, 21, 8
5. Leavens, G. T., Baker, A.L. and Ruby, C. JML: A Java
modeling language. In Formal Underpinnings of Java
Workshop (at OOPSLA’98), pp. 404–420.
6. Milner, R., 1980. A calculus of communicating
systems. Lecture Notes in Computer Science, 92.
John P. Dougherty
Department of Computer Science
370 Lancaster Avenue
Haverford, Pennsylvania 19041 USA
DOI: 10.1145/3328319 Copyright held by author/owner
Figure 1: Execution Trace for Fibonacci (as an example of when not to use multithreading).