As I am currently evaluating some of my courses and didactic measures, I thought I should describe another experience with a flipped classroom concept besides the one in advanced software development. This article describes the course "Concurrency and Parallelism" and the experiences gained from doing the course three times in the last three years. A little background information is in order. Several years ago our faculty had to decide whether to hire an additional professor in web technologies or a new one in concurrency and multi-core technologies. Finally, after long discussions, a professor for web technologies was decided on. As the faculty is part of a so called University of applied sciences, this caused a problem for us and our students because it was very clear at that time, that the future of software development would include much more concurrency and parallelism than before. This is due to the trend to multi-core hardware which again was caused by severe chip-technology problems with the high clock rates. I felt that this absolutely was an essential technology for our students and tried to come up with a solution. Each term I have one "container" course called "current topics" which deals with latest technologies and trends without a fixed program. The summer term course also includes special events and deals mainly with disruptive developments. This course has received a special award in 2017 from the university and is described alsewhere - albeit in German.
Having a course container in a computer science curriculum is nice but by far not enough. I needed content as well and I knew that I would not have time for a large and detailed sript on something as complicated and moving like concurrency and parallelism and new hardware. I knew that I could draw from past experience as an operating systems developer where I dealt with multi-processors, embedded control and realtime problems. Synchronization was of course nothing new to me, but I had missed many the new developments in the non-blocking area of the last years. So what should I do? I decided to "stand on the shoulders of giants" and use available literature like the book by Herlihy and Shavit and others. Mostly books which were not expensive if bought used or from India. And of course some papers.
And to get around writing my own script, I decided to use a flipped classroom approach with mandatory offline reading. At that time I was not really familiar with the concepts as e.g. described by Flipped Classrooms: a Review of Key Ideas and Recommendations for Practice, Sarah J. DeLozier and Matthew G. Rhodes and used some ideas from the peer instruction community instead. To enforce advance reading, I would use micro-exams at the beginning of every session.
As the course was re-dedicated with respect to its content it was clear to me, that a proper announcement would be mandatory in order to get the right students for the class. The following was my announcement and I called the course a "Journal Club" even though this was not the proper term. I use the term now for an advanced seminar in our master program, which is described elsewhere. Now what is a journal club? It means that for this course:
You will read the literature for each session in advance
There will be a test at the beginning of every session
The results will be discussed together
Open questions about the literature will be discussed together
There will be NO LECTURE in those sessions. If you don't read the literature, you won't learn at thing.
WARNING!!!!!!!!!!!!!!!!!!! If you do not have the time to read the papers (and some are quite lengthy), please do NOT participate in this course. You will simply drop out after 3 sessions, as you won't understand a thing being discussed. Last time 36 students started and after a short time became 18, which finished successfully.
We will be using two books: The Art of Multiprocessor Programming by Maurice Herlihy and Nir Shavit. And the seminal "Computer Architecture, a quantitative approach by John L. Hennessy and David A. Patterson. It would not hurt to order them from an Indian Bookstore at a good price...
You will experience problems understanding the papers. This is OK for the first sessions
You will learn to better understand the papers and discover the critical sections (which usually become questions for the tests (:-))
You will learn to ask questions about papers
You will participate in a workshop on concurrency and parallelism, together with the industry. (One Friday afternoon)
At the end of the journal club, you should have learned two things: First, a lot about current concepts and technologies for multicore programming. Second, how to really use papers to get an understanding of advanced engineering topics.
Beginning with the paper "programming paradigms for dummies" by Peter van Roy (to make it clear, that the course would be concept based, not tool or exercise based) an overview of the Java memory model and its consequences for multicore programming, a look at the multicore hardware and its memory hierarchy and consistency mechanisms started the first four sessions. The first session was used to introduce the concepts and let the students decide on some more topics for the course. The reading of the thread-bases parallelism chapter in Hennessy/Petterson turned out to be a real problem for many students despite all of them having gone through an operating system class. Sixty plus pages in one week seems to be a challenge, despite the warning. Caching e.g. was a completely new concept to them.
Next came theoretical topics from the Herlihy/Shavit book and finally algorithms and code from the book. Special topics like transactional memory, CRDTs and functional programming were handled against the end of the course. Once it was possible to organize a workshop with a company to work on a practical problem. This was a chance for the students to use their knowledge.
The course performed roughly the same all three times. At the third session, sometimes the fourth, have of the students had disappeared and decided to take other classes. Around 18 students remained till the end of the course and took the final exam. At the second session, the first micro-exam was distributed and at least half of the students didn't read the per-lecture chapter or paper. They learned that it is embarrassing to sit there with an empty questionnaire and that they were unable to really participate in the discussion of the questions afterwards as so much theoretical background was missing. After one or two more of those experiences half of the students left the class.
For the rest another frustrating experience was waiting: They claimed, that they were unable to answer many questions even though they had read the paper or chapter. And they started worrying about the final exam. But after several sessions they were getting better. This changed again in the seventh or eighth session, when all they received was an empty piece of paper with an empty list of ten numbers. One student disgustedly called out "Are we now even supposed to come up with the questions???" And the answer was "Yes of course!".
And this started a discussion of what had happened with the way they had been reading during the course. They realized that they didn't read properly in the beginning. They skipped difficult sections only to learn after a few sessions, that the questions frequently were about those sections. And the type of questions guided them to actively question the papers when reading them. In other words, they learned that reading papers was a very active task and that they had mostly never learned to read like that. The papers and books btw. were mostly engineering type literature and not hard core scientific papers.
How about the technical content of the course? Using different papers and books automatically brings with it a problem of terminology, understanding and sometimes correctness. It is a very important experience for students to see papers differ substantially about technical things. This was the last lesson to learn in the class and it was usually done by handing out two papers for the next session that defined and handled things very differently. Still the majority of the students just skipped those sections - like to avoid an unpleasent confrontation between the authors. As if a disagreement is something unethical - instead of the basics of all scientific works. This was another lesson to learn for me: We do not encourage students enough to engage in controversal discussions. On the same line: The students did find bugs in complicated algorithms which is also quite satisfying and shows, that even the professionals are not beyond mistakes.
Technically, the major goal of the course was to get an important message across: as a developer you MUST deal with concurrency and parallelism, or your code will be wrong because compiler and hardware do something unexpected, or it will be too slow because you are not using more cores - either by blocking too much or by falling in obscure traps like false sharing. And to learn some basic patterns like compare-and-swap, helping other threads and so on.
Could you do a better course on concurrency and parallelism? Yes, without doubt. With your own script and being a leading expert on those subjects like Herlihy and others, this would be possible any time. But given the limited time and experience, using a flipped learning style not only allowed us to cover the important technological content but at the same time also discover and treat serious reading deficits in students. I even believe this to be the more important lesson!
But what about exercises? There aren't any! I already mentioned that our university is of the "applied sciences" type and lecturers mostly come from the industry with sometimes many years of experience. They - and the students (are not always and not only) "doers". Many foundation courses reserve a lot of time for exercises. But in the last couple of years I have noticed (especially after the introduction of the six-term only bachelor) that there is less time for exercises. This is due to several reasons but the most important one I believe is the increase of know-how in all sciences. This forces us to learn some things theoretically. Because - and that is another reason - without a very sound theoretical base people are no longer able to fix complex problems. I will elaborate on this a litte more in a different post on my distributed systems lecture which changed a lot over the years and reflects exactly this move towards theory. And the last reason is simply that now project type courses exist separately where students can try out things.