Thinking Parallel: The Process of Learning Concurrency Mordechai Ben-Ari
Yifat Ben-David Kolikant
Department of Science Teaching Weizmann Institute of Science Rehovot 76100 Israel Telephone: 972-8-934-2940
Department of Science Teaching Weizmann Institute of Science Rehovot 76100 Israel Telephone: 972-8-934-2493
[email protected] ABSTRACT This paper describes a course in concurrent and distributed computing for high school students and empirical research that was done to study students’ conceptions and attitudes. We found that both their conceptions and their work methods evolved during course to the point that they were able to successfully develop algorithms and to prove their correctness. Students initially found the course extremely challenging but eventually came to appreciate its relevance and its contribution to improving their cognitive skills.
Keywords Concurrency, distributed programming, mental models.
1
INTRODUCTION
We developed a course in concurrent and distributed computing (CDC) for scientifically oriented, but not necessarily gifted, high school students in the twelfth grade. The students are 17-18 years old and are studying in a program of five 90-hour units commencing in the tenth grade. There are two required units on algorithms and Pascal programming and one on elementary data structures. There are electives for a unit teaching a second paradigm (logic programming, assembly language), and for a unit of theory (automata, numerical analysis). Our course is taught in 45 hours as one half of the theory unit. We first explain the motivation for teaching a course in CDC to high school students as a part of the computer science curriculum. Then we explore the goals of the course they are derived from the goals of science teaching. We present the syllabus and the format of the
[email protected]
course, as well as our didactic approach. Next we describe the research that was conducted and analyzes the findings, and finally, we discuss these findings and describe directions for further research.
2
WHY STUDY CDC?
The main goals of science teaching are to help students understand the world around them and to become science-literate in order to function in the modern world. Another goal is to develop skills such as critical and creative thinking, problem solving and good work habits. A further goal is to challenge the students. The additional goals of computer science teaching are based on the belief that computers have a decisive influence on the way we live and that educated people should be computer-literate. The main concepts in the computer science curriculum are: algorithmic problems, algorithms as solutions to these problems, programs as implementation of the algorithms and the correctness of the programs. We claim that a course in concurrent and distributed computation fits these goals. First, the world is parallel. We can explain the world better by using tools that look at systems as cooperating components, rather than looking at the individual components. Second, we are surrounded by distributed and concurrent computerized systems, such as automatic teller machines, Internet browsers, PC operating systems. What is the specific contribution of a course in CDC to the CS curriculum? CDC is significantly different from sequential computing because of its nondeterministic behavior and because of the communications and synchronization needed between components of a system. Nevertheless, a course in CDC naturally fits in with other CS courses because it also emphasizes algorithms as solutions to algorithmic problems, and because the concepts of correctness, abstraction and modularization are extensions of the concepts in sequential programs. As is usual in modern CS courses, our emphasis is on algorithms rather than on language or architecture. Finally, the challenging nature of the subject ensures that students must learn how to use critical thinking rather than hacking.
3
SYLLABUS
The course is composed of 9 chapters. The content of the syllabus was influenced by many articles and books on CDC, for example [2, 1, 6, 3]; obviously, the level of presentation was adapted to a level appropriate for high school students. • Chapter 1 presents the basic concepts of CDC such as system, coordination, distribution and communications, using examples of real world systems such as the telephone system. The concept of failure in a concurrent system is also demonstrated. • Chapter 2 describes the structure of concurrent algorithms and the concurrent Pascal dialect used for implementation. The first formal concurrent algorithm that the students are given is radix sort [8]. • Chapter 3 presents the mutual exclusion problem in a shared memory model. The case study is about two robots that are to sweeten a glass of juice with exactly one sugar cube. The important concepts in this chapter are mutual exclusion, correctness, interleaving and critical section.
The third stage takes place in the lab. The students work with a concurrency simulator on two levels: (a) analyzing algorithms presented in class in order to better understand their behavior, and (b) solving a problem by writing an algorithm and implementing it as program in concurrent Pascal.
4.1
A Sample Lesson
The following case study is used to introduce the mutual exclusion problem: A glass of juice needs to be sweetened by exactly one sugar cube. Two robots execute the following algorithm: taste the juice if it is not sweet then go to the kitchen take a sugar cube come back add the sugar cube to the juice
During class discussion, the students are asked to decide if the algorithm is correct. The students dramatize several scenarios of the algorithms: two of them play the role of robots and one the role of the scheduler. They conclude that sometimes the algorithm works and sometimes it does not. This leads us to the definition of a corChapter 5 extends the concept of correctness and introduces rect algorithm as one that performs as specified for every scenario invariants for proving correctness. Concepts studied in this and to a method of proving that an algorithm is wrong, namely, the chapter are: liveness, safety, deadlock, starvation and invaricreation of a falsifying scenario. ant. The students are then asked to correct this algorithm. Every solution Chapter 6 solves the dining philosophers problem. The semaphore is written and dramatized to help analyze its correctness. At the type is extended to the counting semaphore. This chapter can end of the session students see that with the tools they have it is be omitted if time is short. impossible to write a correct algorithm, because between the action Chapter 7 presents the Linda tuple-space model as an alterof checking the need to sweeten and the action of adding the sugar nate synchronization model so that students are not locked cube the scheduler can interleave arbitrary actions of the other robot. onto the semaphore as the only possible model. In the laboratory, the students are asked to create the falsifying scenarios. Later when they learn about semaphores, they are asked to Chapter 8 turns from concurrent to distributed systems and write a program that solves the problem. presents the model of message passing in asynchronous systems. The focus is on the Ricart-Agrawala algorithm for distributed mutual exclusion. 5 RESEARCH IN THE CLASS
• Chapter 4 presents binary semaphores. The case study is about two hungry brothers who want to cut pieces of cake, sharing one knife. •
•
•
•
• Chapter 9 discusses reliable systems in the distributed model through a guided development of the Byzantine Generals algorithm including a correctness proof.
4
HOW DO WE TEACH CDC?
Teaching CDC in high school is challenging because the students are less mature and less able to deal with formal material than university students. Our approach is to present concepts and algorithms in a concrete setting before discussing formal aspects. Each topic is taught in three stages. First, the problem is presented using a case study. The students discuss the problem and suggest solutions, employing the tools they have already acquired. They use dramatizations ([8, 4]) to understand the execution of their algorithms and to determine possible failures. In the second stage, the case study is formalized, and new tools such the semaphore are introduced as needed. The students study an algorithm that solves the problem and analyze its correctness.
The rest of the paper describes research done by the second author as part of her graduate work under the supervision of the first author. (Note that students in our department are trained in the methods of educational research.) Qualitative research was done in order to: (a) identify the students’ difficulties, (b) understand the sources of the difficulties and, (c) discover the attitudes of the students to the course. The methods used were to collect tests and assignments, and to videotape interviews and problem-solving sessions. The following subsections summarize the findings.
5.1
Difficulties
We found that students difficulties can be classified into major categories: • Understanding the concept of ‘model’ • Misconceptions of the various models • Difficulties with coordination
5.2
Understanding the Concept of ‘Model’
Students do not understand the concept of a model. A model is specified by the types and operations that it defines. Students ignored the specification and invented new operations. For example, the tuplespace model is specified by the tuple data type (that we call a ‘note’) and by three operations: post, remove and read note. A few students invented new operations such as: while the note you are waiting for has not arrived do and look if the note has arrived Students who invented operations in one model tended to do so in others as well! For example, a pair of students suggested that the dining philosophers: look if the fork is on the table before sending messages to each other This difficulty was more common in pseudo-code algorithms than in programs. Based on interviews with the students, we believe that the reason is that students talk to the computer as they would talk to a human being, and pseudo-code algorithms give them a sense of freedom to do so more than do programs. This confirms findings by Pea [5] and Resnick [7].
5.3
Misconceptions of the Models
Students interpret the model operations and make assumptions of its behavior that are not necessarily consistent with the formal specifications. For example, in a distributed asynchronous system using message passing, students assumed that if node A sends a message to node B and then node C also sends a message to node B, the messages will arrive in order that they were sent even though the model does not make this assumption. The reason is that the students make assumptions based on informal concepts rather than using the formal rules; in this example, they assume a global clock where none exists.
5.4
Difficulties with Coordination
Some students did not even attempt to use concurrency and gave sequential algorithms for the problems. For example, even when there was potential parallelism in a problem, one student suggested a sequential solution and claimed that it was correct because it satisfied the precedence requirements. When analyzing or developing an algorithm, some students who did use concurrency did not always identify suspicious scenarios. This problem appeared at two levels: some students simply did not search for suspicious scenarios, or limited their checking to a single scenario. For example, one student claimed that if each individual process is correct the entire program is correct. At a higher level, some students checked coordination but did not do it well, to the extent that some tried to solve coordination problems using only sequential Pascal. There are several explanations for the source of these difficulties. One is that students are so used to sequential computing that they
routinely use sequential strategies for problem solving. Furthermore, their work habits remain those of sequential programming. This is most apparent when proving correctness. In sequential programming, an algorithm is generally a function from an input to an output, and it is usually sufficient to choose representative inputs and run the program on them, debugging (step-by-step execution) as necessary. A correct algorithm in CDC must give the correct output (or reactive behavior) not only for every input, but for every possible scenario on those inputs. Furthermore, there are correctness properties in CDC such as deadlock-free and starvation-free that have no equivalent in sequential programming. Thus correctness is a theoretical issue rather than a lab assignment.
5.5
Students’ Attitudes
Many students initially felt embarrassed taking part in the ‘stupid’ dramatizations, but eventually came to regard them as central to understanding the algorithms. All of the students agreed that the course requires thinking. Some of them liked it, saying that it challenged them; others—a minority—claimed that they do not like to think! Students liked the fact that the case studies are from real life and felt that the course contributed to their understanding of computerized systems. In addition, they believed that the course contributed to their problem-solving abilities. The main result that we found was that students’ attitudes towards correctness proofs evolved during the course. Initially, they failed even to appreciate that correctness is a central issue that takes on a new and unfamiliar guise in CDC. Then, they became almost hysterical as they understood its implications. Finally though, most students were able to give correctness proofs. If fact, the students considered correctness as an essential part of algorithm development in CDC.
5.6
A Process of Evolution
We noticed significant change in the students’ performance during the course. Their work methods improved as did their understanding of concurrency concepts and their interrelationship. The began to take responsibility for the quality of their solutions and they adopted methods to ensure correctness. In this subsection, we will demonstrate this evolution by focusing on one student. Y. is a gifted student who gets excellent grades in CS courses. At the beginning of the course, Y. claimed that CDC is just another programming language and that it is very easy to learn the material. He said that he never writes algorithms in pseudo-code before writing a program, and that there is no need to verify correctness because he knows what he is doing, and it is sufficient to check the execution of the program on a computer. When we mentioned that there are many possible scenarios, he said he can run the program again and again, and eventually the bad scenarios—if they exist—would occur. He made mistakes that can be classified as not understanding the model concept and difficulties with coordination. He claimed that if he wrote each process correctly, then the complete program is correct. At the end of the course, he participated in a problem-solving session with another student. His first comment to his partner was that they need to start by designing an algorithm! After each stage of algorithm development, he carefully checked coordination, identi-
fying problematic areas and examining suspicious scenarios. He no longer used sequential tools to solve coordination problems, but he still tried to invent new operations instead of staying within the model. His attitude had also changed so that he appreciated the challenge of studying CDC.
6
DID THE COURSE ACHIEVE ITS AIMS?
This question must be answered relative to the goals presented above. • Problem solving. The students learned basic concepts, problems and algorithms in CDC. We noticed a process of getting used to the unique character of CDC as the course progressed. By the end of the course most students were able to solve problems of process coordination in the various models. They adopted work methods for proving correctness as part of the problem-solving process. Their marks in the final exams were very high. • Explain the world. Students could give real-world examples that exemplified concepts that were learned in the course. They could explain systems behavior in technical terms. For example, one student said during an interview: “Ordering flight tickets from all over the country is a system with a critical section.” • Skills. At the beginning of the course students worked on their own. Discussions were not very fruitful because the students talked only with the teacher. Because assignments required theoretical analysis and not just hacking, they had to work in teams, and learned to listen to and to criticize each other. We have recently completed a trial in which the course was taught by two teachers who were not part of the development team. Since the teachers had not studied CDC during their training, they were quite apprehensive and required close support from us. Teacher training will be our major challenge as we introduce the course to a larger population.
7
CONCLUSION
As a result of our analysis of the students’ difficulties, we have learned the importance of the model concept in teaching CDC, and have changed the syllabus and the didactic approach appropriately. We now emphasize the teaching of models throughout the course. The students’ performance during the course kept improving: students learned to deal with new models and to solve algorithmic problems in a model. They enjoyed the course although it was not easy. They made connections from the subject matter to the real world, and improved their problem solving abilities as well as their work and social skills. In the future we plan to examine the evolution of students’ conceptions and work methods, and their influence on each other. We hope that this will improve our understanding of learning CDC and enable us to improve the course.
REFERENCES [1] Gregory R. Andrews. Concurrent Programming: Principles Practice. Benjamin/Cummings, 1991. [2] M. Ben-Ari. Principles of Concurrent and Distributed Programming. Prentice-Hall International, 1990.
[3] Jos´e C. Cunha and Jo˜ao Lourenc¸o. An integrated course on parallel and distributed processing. In Twenty-Ninth SIGCSE Technical Symposium on Computer Science Education, pages 217–221, Atlanta, GA, 1998. [4] William S. Lloyd. Exploring the Byzantine Generals problem with beginning computer science students. SIGCSE Bulletin, 26 (4):21–24,28, 1994. [5] Roy D. Pea. Language-independent conceptual “bugs” in novice programming. Journal of Educational Computing Research, 2(1):25–36, 1986. [6] N. Plouzeau and M. Raynal. Elements for a course on the design of distributed algorithms. SIGCSE Bulletin, 24(2):35–40, 1992. [7] Mitchel Resnick. Beyond the centralized mindset. Journal of the Learning Sciences, 5(1):1–22, 1996. [8] Adam Rifkin. Teaching parallel programming and software engineering to high school students. In Twenty-Fifth SIGCSE Technical Symposium on Computer Science Education, pages 26–30, Phoenix, AZ, 1994.
