Using Experiments to Learn Abstract Computer Science Concepts. M.Sc. Thesis by Sidsel Jensen

Transcription

1 Using Experiments to Learn Abstract Computer Science Concepts M.Sc. Thesis by Sidsel Jensen Department of Computer Science University of Copenhagen July 2009

2 Abstract The scope of this thesis is set within the field of teaching computer science. The author has developed a set of real-world experiments designed for the pre-college audience. These experiments have been developed in accordance with current educational principles and theories, and special emphasis has been put on motivation of the students through the use of active experimentation. The primary concepts for these experiments are concurrency, threads and synchronization principles and related subjects. Three different hardware platforms have been evaluated, and one has been chosen and used for the practical implementation of the experiments. A subset of the experiments has been tested on a group of students, using the thinking aloud method with promising results. We found that experimentation is a valid teaching method which allowed the students to work focused with difficult concepts at different levels of abstraction. i

3

4 Contents 1 Introduction Thesis problems Teaching experimentation The target group Contributions Outline Related Work Learning theories Learning by doing Zone of proximal development Scaffolding Constructionism Experiential learning Teaching examples Using the BlackBerry Using real-world examples Summary Identifying the Concepts Concept Inventories Fundamental Ideas Choosing the concepts Concurrency Threads Synchronization Summary The Experiments Choice of computing platform The LEGO Mindstorms NXT platform The Sentilla Perk platform The SunSPOT platform

5 CONTENTS CONTENTS Comparison of the platforms Design of the experiments Experiment 1: The Elevators Experiment 2: Lock that door Experiment 3: The Twittering Computer Scientists Design choices The academic lesson plan Implementing the Experiments LEDs and switches The accelerometer Radio communication The Squawk virtual machine Threading Summary Test and evaluation Results Conclusion Future Work A Experiment descriptions 57 A.1 Experiment A.2 Experiment A.3 Experiment B Lesson slides 63 B.1 Lesson B.2 Lesson B.3 Lesson C Source code 87 C.1 Experiment 2 - LockTheDoor-onSPOT Application.java C.2 Experiment 2 - LockTheDoor-onHost SunSpotHostApplication.java C.3 Experiment 2 - LockTheDoor-onHost SpotRadio.java C.4 Experiment 3 - TwitteringCS-OnSPOT Application.java C.5 Experiment 3 - TwitteringCS-OnHost SunSpotHostApplication.java D Video transcriptions (in Danish) 119 D.1 Transcription of TA test D.2 Transcription of Small-talk after TA

6 Chapter 1 Introduction In a time, where computers, game stations and cell phones are common household items and growing in numbers, it s remarkable how the technology and science put into the development of the products is of little or no interest to the users. Many people simply consider computers and computer science some what dull and boring subjects and their interest tends to drop below the freezing point, when the talk turns towards computers. However - computers are being used in almost every aspect of our daily lives, and computer science is at the core driving innovation - bridging over to other fields of science and there is a growing need to expose students to the broad and ubiquitous nature of the field. Perhaps the time has come to recover some of the magic and beauty of computer science? In dire contrast to the new and improved ways we are using computers and software, is the way we are taught computer science. It has not changed much in the last couple of decades. Traditionally it consists of a number of lectures, followed by a number of exercises, home work and maybe even a couple of lab-exercises or a longer assignment. Perhaps we should consider rebooting the way we teach computer science? Many have attempted to take on a different approach to teaching computer science and especially programming classes, perhaps most notably the Alice Project 1 and derivatives like KidSim/Cocoa, project Greenfoot 2, Scratch 3 and newest Microsoft Kodu 4 (formerly known as Boku) which all try to teach children programming through a visual environment. Some has been more successful than others, like using Alice for storytelling in middle schools 5, however the big breakthrough in teaching visual programming hasn t really settled in, so it might be that the focus is wrong? What if we shouldn t focus so much on the tools, but rather on the concepts?

7 1.1. THESIS PROBLEMS CHAPTER 1. INTRODUCTION Computational thinking is a way of solving problems, designing systems, and understanding human behavior that draws on concepts fundamental to computer science. Computational thinking could be a fundamental part of the way people think and understand the world and what if we could add computational thinking to every child s analytical abilities? [Wing06]. Teaching is in essence providing the students with the skill set for the future. We need to provide them with the right mental tools for the 21st century, but what might be an effective way of learning (teaching) computational thinking to children/students? This thesis attacks this specific question. 1.1 Thesis problems We wish to explore whether: A changed way of teaching computer science could appeal to a greater number of students, who are currently alienated by the traditional passive blackboard-based lectures? Can we increase the motivation and active participation of the students by changing to experiment-based teaching? We by selecting a limited number of computer science related concepts and by creating a number of teaching experiments based on these, provide the students with a level of understanding that current teaching methods does not provide? 1.2 Teaching experimentation Other fields within the faculty of sciences, like physics 6 have recently had really good academic results with introducing experimentation in their undergraduate teachings, rising the students participation in classes and rising the overall level on later exams. Studies in the US [Hake98] on 6000 physics students confirms these findings and shows, that both the gifted as well as the ordinary students benefit substantially by the more active experiment based classes. The question remains though, whether something similar could be done within the field of computer science. Computer Science is in its essence an experimental science like biology and physics and exercises are valuable because they help students relate abstract concepts to concrete programs. Building concrete intuition for abstract concepts is a vital goal in introductory computer science courses /fra tavleundervisning til eksperimenter/ 4

8 CHAPTER 1. INTRODUCTION 1.3. THE TARGET GROUP 1.3 The target group We need to reach the pre-college audience, including teachers, parents and students and expose them to computational methods and models. We need to spread the power of being able to think like a computer scientist, which requires thinking at multiple levels of abstraction and using different ways of automation, to make computational thinking commonplace[wing06]. In order to get an idea of the level of teaching possible for the pre-college audience, we visited a local high school (Naerum Gymnasium) and gave 4 classes (each 2x45 minutes) to a class of computer science students in their last year as a pre-study to this thesis. The classes taught were focused on sensor networks and the topics were: An introduction to sensor networks The hardware used in sensor networks The software used in sensor networks The network in sensor networks A small experiment The small experiment was based on an echo program, running on 2 small 8-bit Freescale motes 7 and the students were asked to (a) figure out how long the wireless radio distance was in meters and (b) figure out what it would take to kill the radio signal. They were given 30 minutes to solve the task. Many creative and inventive solutions were tried by the students, like taking the motes outside and moving them further and further away from each other while watching the echo-output on a laptop. Others were wrapping the motes in tin foil to strangle the radio signal. It was a good experience and it gave us an immediate understanding of what might work and what didn t when teaching this particular age group. 1.4 Contributions Our contributions in this thesis are the following: We have reviewed a number of different learning theories and a couple of teaching examples and we propose a renewal of the teaching methods using experimentation with a higher focus on motivating the students through active participation. We have analyzed a number of computer science concepts, which are all considered hard to understand and developed a set of three experiments, that are based on real-world examples incorporating the concepts, that can be used for the pre-college audience

9 1.5. OUTLINE CHAPTER 1. INTRODUCTION The experiments are organized within a lesson plan, which could fit into an optional module on a high school teaching the course computer science 8. Each experiment is coupled with a set of teaching materials (a slide set and talking-points) introducing the concepts being used in the experiment. Furthermore the experiments and the teaching materials have been tested, validating their relevance as a possible teaching method. We found that experimentation is in fact a fully functional and very motivating teaching method that allowed the students to work focused with the different and difficult concepts at different levels of abstraction. 1.5 Outline In the first part of this thesis, we review which learning theories, education materials and methods already exists (Chapter 2). We then analyze which computer science concepts to base the experiments on (Chapter 3), and describe the planning and organization of the experiments (Chapter 4). We then proceed to test and evaluate the experiments (Chapter 5) and finally we conclude on the findings and discuss future work (Chapter 6). 8 In Danish terms - Datalogi C 6

10 Chapter 2 Related Work In this chapter we will analyze a number of different learning theories and for each learning theory we wish to draw attention to different aspects which will be incorporated into the experiments and teaching materials. We will also analyze two examples of computer science teaching materials, which are based on different aspects of the learning theories. 2.1 Learning theories The major learning theories can be divided into three schools: Behaviorism in which the focus is on the students outer observable behavior Cognitivism in which the focus is on the students inner mental processes and Socio-culturalism in which the focus is on the students participation in different social contexts According to behaviorism, knowledge is objective and quantitative. It is located outside the individual and can be defined and classified. Learning is perceived as an accumulation of stimulus-respons-associations. A couple of the consequences for teaching and testing can be listed as the following: 1. Learning is an accumulation of little bits of knowledge. 2. Learning has to be organized sequentially and hierarchical. 3. Transference between different knowledge areas is limited. 4. Tests are given often to assure comprehension before moving on to new subjects. 5. The motivation is outer and based on positive support of many small steps 7

11 2.1. LEARNING THEORIES CHAPTER 2. RELATED WORK As one might realize, this approximation have had very strong influence on the way current curriculum, teaching and testing have been developed in most countries. From a behavioristic point of view, students have to learn basic facts step-by-step and one does not expect them to be able to think, reflect and use the knowledge they have gained until much later. We know today, that this is not the single-handed truth. Cognitivism on the other hand, focus on the individual and is built on two key assumptions (1) that the memory system is an active organized processor of information and (2) that prior knowledge plays an important role in learning. Cognitive theories look beyond behavior to explain brain-based learning. Cognitivism thus has a more positive take on the transference of knowledge from one field to another, but under the assumption that students understand the general principles behind a given problem. Cognitivism has been predominate since the late 1970 s, but during the last ten years many cognitivists has put a growing emphasis on the social and cultural contexts. The critics of cognitivism believes that cognitivism has a tendency to focus too much on the individual and the mental part of learning. Socio-culturalism switches the focus from that of the individual to that of the group. Learning cannot be understood as a process that is solely in the mind of the learner, but instead knowledge is distributed over mind, body and its surroundings and is constructed in settings of joint activity. Socio-culturalism is based on six important aspects of learning [Dysthe03]: 1. Learning is situated - based on authentic activities 2. Learning is fundamentally social 3. Learning is distributed between persons with different skills 4. Learning is mediated by different tools 5. Learning is participation in a community of practice 6. The language is key in the learning process Learning by doing John Dewey ( ) - was an American philosopher, psychologist, and educational reformer whose thoughts and ideas have been highly influential in the United States and around the world. Dewey, is recognized as one of the founders of the philosophical school of pragmatism. Although Dewey did not identify himself as a pragmatist per se, but instead referred to his philosophy as instrumentalism. Dewey was the most famous proponent of hands-on learning or experiential education, which is related to, but not synonymous with experiential learning. Dewey belonged to the school of socioculturalism. 8

12 CHAPTER 2. RELATED WORK 2.1. LEARNING THEORIES Dewey s extensive and versatile authorship has been the constant inspiration to all, who were unhappy with traditional educational theory and practice. Dewey s pragmatic view on knowledge imply that knowledge is created through activity and that the context of the situation is important. We might recognize this view from some math exercises - like figuring out how long it takes to go from point A to point B by mule. We believe a good teaching strategy is to place instruction in a meaningful context. In modern usage it is often known as situated learning. This means to use less abstract presentations of material but to let students experience a more real-world setting preferably in an active way Zone of proximal development Another dominant socio-culturalist was Lev Vygotsky ( ). He was a russian pioneering psychologist, who sadly died of tuberculosis at the early age of 38. His early death and Stalin s regime in Russia, meant that much of his work wasn t published in the West and he was only rediscovered several years later. The zone of proximal development (ZPD) is Vygotsky s term for the range of tasks that are too difficult for the child to master alone but that can be learned with guidance and assistance of adults or more-skilled children. The lower limit of ZPD is the level of skill reached by the child working independently. The upper limit is the level of additional responsibility the child can accept with the assistance of an able instructor. The ZPD captures the child s cognitive skills that are in the process of maturing and can be accomplished only with the assistance of a more-skilled person. We believe a good teaching strategy is thus, to place students with different knowledge levels in groups together, making them able to function as the instructor for each other Scaffolding Scaffolding is a concept closely related to the idea of ZPD. Scaffolding is changing the level of support. The term scaffolding was not coined by Lev Vygotsky himself, but rather by Jerome Bruner (born 1915). Instructional scaffolding is the provision of sufficient support to promote learning when concepts and skills are being first introduced to students and it s defined as a temporary framework for construction in progress. The scaffolds provided by the tutor do not change the nature or difficulty level of the task; instead, the scaffolds provided allow the student to successfully complete the task. Bruner s theory of how children construct knowledge involves three basic modes of instruction - enactive, iconic and symbolic. An implication of Bruner s developmental theories is that children should be provided with study materials, activities, and tools that are matched to and capitalize on their developing cognitive capabilities. In his 9

13 2.1. LEARNING THEORIES CHAPTER 2. RELATED WORK much-translated book The Process of Education [Bruner60] Bruner famously argued that any subject could be taught to any child at any stage of development, if it is presented in the proper manner. Therefore, students at the enactive stage should be given the opportunity to play with the materials in order to fully understand how it works. In the second stage, iconic, students are capable of making mental images of the material and no longer need to manipulate them directly. Here students are able to visualize concrete information. The symbolic stage, is the final stage in which students can use abstract ideas to represent the world. Students must go through all of these stages successively in order to connect new ideas and concepts if they are to generate their own understanding. Using scaffolding allows students to become independent learners. Bruner s work also influenced Xerox PARC researchers in their efforts to create graphical user interfaces (GUIs) that addressed the enactive, iconic and symbolic ways users understand and manipulate the world around them. Bruner was instrumental in the move from behaviorism to cognitivism in the 1950 s. We believe a good (perhaps obvious) teaching strategy is to adapt the lessons and teaching materials to the target group. In our case we are not addressing children but rather older students, which master all three stages, but by differentiating between the three modes of representation one can reach out to a broader group of students, which might dislike say a pure symbolic representation Constructionism Seymour Papert (born 1928) was the developer of an original and highly influential theory on learning called constructionism, built upon the work of Jean Piaget ( ) in Constructivism learning theories. Constructivism is a psychological theory of knowledge (epistemology) which argues that humans generate knowledge and meaning from their experiences. Constructionist learning (the learning theory) is inspired by constructivist theories that learners actively construct mental models and theories of the world around them. Popular known as learning-by-making. According to Piaget, learning is an active constructivism where students receive information, interpret it and unite it with what they already know and if necessary they reorganize the existing mental structures to adapt the newly gained knowledge. The ability to think and form concepts grows from situations where the student does trialand-error and is active, rather than by absorbing what others say. Bruner was also heavily influenced by Piaget and a major theme in Bruner s theoretical framework is that learning is an active process in which learners construct new ideas or concepts based upon their current/past knowledge. Bruner believed that making 10

14 CHAPTER 2. RELATED WORK 2.1. LEARNING THEORIES mistakes was necessary in order to gain knowledge, that learning occurs through problem solving. Through the active process of discovery and trial and error the student can uncover the interrelationships between concepts and ideas, which allows them to gain knowledge about new truths. This process of making mistakes is a necessary process in order to discover the facts about the concept. Papert has been a huge proponent of bringing IT to classrooms [Papert83], as in his early uses of the Logo language 1 to teach mathematics to children. Heavily inspired by Paperts work, Lego launched its Mindstorms Robotics Invention System in The educational version of the products is called Lego Mindstorms for Schools, and comes with the Robolab GUI-based programming software, now using the graphical programming language National Instruments LabVIEW 2 as an engine. We believe a good teaching strategy is to allow students to interact with the world by exploring and manipulating objects, wrestling with questions and controversies, or performing experiments. When developing problem-based learning skills, students are more likely to remember concepts and knowledge discovered on their own. Also students build knowledge based on previously learned information in a spiraling fashion, which enables learners to connect prior schematic concepts, so a spiral curriculum could be the answer Experiential learning The idea of learning through experimentation or experiential learning, is of course not new. It was coined by the American educational theorist David A. Kolb (born 1939), who was inspired by Dewey, Piaget and Lewin. Experiential learning is learning through reflection on doing. It is subjective, concrete, interactive and complex and we can define the abilities required as: 1. the learner must be willing to be actively involved in the experience 2. the learner must be able to reflect on the experience 3. the learner must possess and use analytical skills to conceptualize the experience 4. the learner must possess decision making and problem solving skills in order to use the new ideas gained from the experience. He created his model out of four elements: concrete experience, observation and reflection, the formation of abstract concepts and testing in new situations. He represented these in the famous experiential learning circle: LabVIEW is short for Laboratory Virtual Instrumentation Engineering Workbench 11

15 2.1. LEARNING THEORIES CHAPTER 2. RELATED WORK Figure 2.1: Kolb s experiential learning circle The learning cycle of Kolb tells us how to understand a problem, through an individual cognitive process. Its important to be aware that experiential learning can be problematic as generalizations or meanings may be misapplied. Without continuity and interaction, experience may actually distort educational growth and disable an otherwise capable learner. The key lies in the facilitator and how he or she facilitates the learning process. An effective experiential facilitator is one who is passionate about his or her work and is able to immerse participants totally in the learning situation, allowing them to gain new knowledge from their peers and the environment created. The benefits of experiential learning are many. It teaches the student to experiment scientifically, and encourages them to learn through individual exploration [Baldwin92]. Group based experiments enhances self-teaching within the group and helps develop communication skills. The hands-on approach motivates the student, but also enables better understanding of the underlying concepts. Retention statistics show that students retain over 90 percent of the material to which they are exposed if they are required to use the material immediately or engage in teaching others. Students need opportunities for well-planned, thought-provoking, supervised and evaluated learning experiences in situations similar to those they will face once they leave the university. For experiential learning to occur within the classroom, the instructor must use strategies that simulate or incorporate real-world situations. We believe a good teaching strategy is to plan the lectures to be purposeful with explicit goals and intended outcomes. Also the experiences should provide opportunities for reflection. And last but not least the experience should be supervised. 12

16 CHAPTER 2. RELATED WORK 2.2. TEACHING EXAMPLES 2.2 Teaching examples The good examples are rare and hard to come by, but in the following sections we will review two such alternatives Using the BlackBerry At the University of Guelph, Canada they are teaching introductory programming using the BlackBerry Wireless Device [Mahmoud07]. The BlackBerry device is a general purpose communicating device which can be programmed using the Java Platform Micro Edition (ME), which runs on 85 percent of todays mobile devices. The courses are lab-extensive where students experiment with the devices and develop and deploy applications for them. The main incentive while developing the course was the widening gap between academic environments and how students of today use their personal computers. By introducing the BlackBerry devices into programming courses, they have narrowed that gap substantially and allowed students to work on more interesting and exciting assignments. The students were motivated by the development challenges they were presented with, and the teachers were thrilled to see the students move beyond their normal comfort zone. The students felt they were given an advantage over other students, with their newfound expertise in wireless mobile application development 3. The teachers put a lot of effort into the lab-exercises and combined it with pair programming, to enable knowledge sharing between students. The programming groups were selected by the teacher to get a fair pairing process, and the groups were rotated for each lab-exercise and assignments. To put it in terms of learning theory the focus was on active learning-by-doing in the lab and within a social context with the use of pair programming. As for the assignments, the students were asked to develop a mortgage calculator or experiment with a stock portfolio application, making the learning situated. Using the Java ME platform as a tool also allowed the students to later transfer their knowledge to other fields of interest Using real-world examples At the University of ETH in Zurich they have developed 2 real-world learning applications, LogicTraffic and QueueTraffic, which teach propositional logic and queueing theory respectively to high school students in Switzerland [Arnold07]. The foundation was to introduce fundamental abstract and formal topics through well-known examples - in this case a Traffic scenario. The two applications introduce a number of im- 3 qa.html 13

17 2.3. SUMMARY CHAPTER 2. RELATED WORK portant computer science and mathematical concepts and despite their importance for scientific disciplines, neither are normally taught at high schools. LogicTraffic is using an intersection/traffic light metaphor, which allows the students to quickly connect the concepts of propositional logic (PL) to a well-known situation. QueueTraffic allows the students to simulate and analyze traffic jams at an intersection, with the possibility to manipulate different system parameters like the arrival rate of cars. Both applications have a high degree of interactivity 4. Figure 2.2: Screenshot from LogicTraffic The design of both applications are built upon two distinct didactical principles: fundamental ideas and different representations. The different representations are highly influenced by Bruner and incorporates a number of different views where formulas and truth tables offer a symbolic representation. A static picture of the traffic situation offers an iconic view and through mouse-clicks one will achieve a virtual-enactive mode which shows an animation of the situation. Fundamental ideas on the other hand, guarantees that the selection of content is cognitively demanding, relevant and long-lived [Schwill96]. Thereby justifying the high cost of development time for such a specialized learning environment. 2.3 Summary In Denmark we currently have two highly successful technical science parks/museums, which have been the pioneers within Danish research-based dissemination of knowledge. Both Experimentarium 5 and Danfoss Universe 6 has implemented experiential learning in their core exhibitions. At the Universe Research Lab 7, which is the educational research centre of Danfoss Universe, they are currently working on establishing the teaching facilities of the future and the project aims at contributing to the development of new learning environments for natural and technical science subjects

18 CHAPTER 2. RELATED WORK 2.3. SUMMARY as well as closing the gap between formal and informal learning environments. The objective is to promote the improvement of the teaching level and methods used in the science subjects. This is very much in line, with the goal for our experiments. We wish to develop a number of experiments that can be used for the pre-college audience 8 to teach them computer science concepts within the scope of computational thinking. It is our belief that the experiments can be used both for exploration and for the illumination of difficult concepts [Knox96]. The following is a list of our didactical requirements to the experiments, based on the above mentioned learning theories. We didn t find one single learning theory, which stood out and contained all the necessary components, so instead we have picked a combination of elements, which will constitute our list of requirements. The learning experience should: involve the application of computer science concepts involve a hands-on approach to motivate the students incorporate active learning, with the student as an active participant present a continual challenge to the student be group-based to enable the instructional scaffolding in a social context use real-world examples to improve knowledge transference try to support different modes of representations and be enriched, with access to materials, resources and support systems. 8 In Danish high schools - Gymnasiums 15

19 2.3. SUMMARY CHAPTER 2. RELATED WORK 16

20 Chapter 3 Identifying the Concepts In this chapter we will take a closer look at the concepts. We will discuss and decide which computer science concepts to base the experiments on and describe them in detail. An important aim of instruction in schools is that the students get acquainted with the concepts that are used within specific domains, and that they improve their ability to use these concepts in their mutually agreed upon scientific meaning. Academic disciplines are characterized by many discipline-bound concepts and ways of reasoning, sometimes referred to as professional jargon. However, different explanations are provided to explain why students have problems learning to use concepts in their scientific meaning. Some of these explanations draw on the idea of a difference between the everyday use of concepts and ways of reasoning when compared with more scientific ones. 3.1 Concept Inventories One such tool for catching misconceptions is a Concept Inventory (CI) [Goldman08]. It is a structured way to test students and to identify important concepts within a field. It is basically a multiple choice test, where all the distractor answers are based on commonly held student views. As a result the most important role for concept inventories is to provide instructors with clues as to the ideas, the scientific misconceptions and/or conceptual lacunae, with which students are working, and which may be actively interfering with learning 1. Concept Inventories are very popular within physics, where the Force Concept Inventory (FCI) demonstrated that even students who had excelled on conventional examinations failed to answer simple, conceptual questions on the FCI correctly. 1 Test of students perception of concepts F.pdf 17

21 3.2. FUNDAMENTAL IDEAS CHAPTER 3. IDENTIFYING THE CONCEPTS Unfortunately no common concept inventory currently exists for computer science. If one had existed it would have been an obvious way for us to select a number of concepts which had a high score of misconceptions and base the experiments on these. The Concept Inventory test could have been applied before running the experiments and after in order to better control the benefit of the experiments in terms on concept understanding. One could only hope that such a strong tool is developed for teachers and educators within computer science in the future. 3.2 Fundamental Ideas Due to the dynamic evolution of computer science new subjects arise permanently, grow up and become a regular branch before they are being included into the computer science curriculum. Since each student will probably face several paradigm changes in future life with much of the respective knowledge becoming obsolete each time, the skills acquired earlier must be robust to latest fashion and enable the student to cope with the changes. Hence, it is necessary that students obtain a sketch of the fundamental ideas, principles, methods and ways of thinking of computer science. Only these fundamentals seem to remain valid in the long term and enable students to acquire new concepts successfully during their professional career [Schwill96]. A fundamental idea with respect to some domain (e.g. a science or a branch) is a schema for thinking, acting, describing or explaining which: 1. is applicable or observable in multiple ways in different areas (of the domain) (horizontal criterion) 2. may be demonstrated and taught on every intellectual level (vertical criterion) 3. can be clearly observed in the historical development (of the domain) and will be relevant in the longer term (criterion of time) 4. is related to everyday language and thinking (criterion of sense). Hence, fundamental ideas are widely applicable in many contexts and organize and integrate a wealth of phenomena (horizontal criterion). A fundamental idea can be taught on almost every level of understanding, i.e. on the level of a primary school as well as on the university level (vertical criterion). Presentations differ only by level of detail and formalization. Teaching through the use of fundamental ideas might help bridge the gap between the knowledge acquired in high school to the knowledge being taught at university level. As for the experiments, we will try to pick a number of concepts, which can be considered fundamental ideas within computer science. It will give us the freedom to 18

22 CHAPTER 3. IDENTIFYING THE CONCEPTS 3.3. CHOOSING THE CONCEPTS organize the experiments in a number of different ways, using one or more of the four criterions mentioned above. 3.3 Choosing the concepts We need to select a number of concepts, on which we can base the experiments, but choosing from the massive number of abstract computer science concepts is a daunting task. The experiments are not currently part of an existing computer science course, which only makes the task harder, since we are not bound by a predefined curriculum. In a more constructive manner, we took a look at emerging trends in computer science and quite a few concepts stood out: concurrency, threads and synchronization in particular. In the following, we will describe why those specific concepts were chosen Concurrency Concurrent computing is pervading the world and one cannot underestimate its importance in the future. Other disciplines like bio-informatics have started to use ideas from concurrency theory to model enzyme reactions via stochastic process calculi. So concurrency theory will be far more widespread in the future then it already is nowadays. Teaching the theoretical basis of concurrency is usually only done - if at all - at a late point in curriculum or at graduate level. Since concurrency is notoriously difficult to understand, it is kept implicitly in most courses or only dealt with intuitively and not put on a formal basis, but universities owe the education of computer scientists that are capable of dealing with the challenges of today and tomorrow. It is no secret that concurrency is considered hard [Sutter05]. There are simply more things that can go wrong in a concurrent program, than in a sequential one. Concurrent programs are often non-deterministic, which means it is not possible to tell, by looking at the program, what will happen when it executes. The sequential programming model is intuitive and natural, as it models the way humans work: do one thing at a time, in sequence - mostly. However most students come to a computer science education with a healthy understanding of how to get along in an inherently concurrent world. The base goals of concurrent programming include correctness, performance and robustness. We use the term concurrency control to ensure correct results for concurrent operations are generated, while getting those results as quickly as possible. Concurrent programs can be executed sequentially on a single processor by interleaving the execution steps of each computational process, or executed in parallel by as- 19

23 3.3. CHOOSING THE CONCEPTS CHAPTER 3. IDENTIFYING THE CONCEPTS signing each computational process to one of a set of processors that may be close or distributed across a network. The main challenges in designing concurrent programs are ensuring the correct sequencing of the interactions or communications between different computational processes, and coordinating access to resources that are shared among processes. Communication is usually done in one of two ways: Shared memory communication - where concurrent components communicate by altering the contents of shared memory locations, exemplified by either Java or C#. It usually requires some sort of locking (eg. mutual exclusion or semaphores) to coordinate between threads. Message passing communication - where concurrent components communicate by exchanging messages, exemplified by either Erlang 2 or Occam 3 (which is based on Communicating Sequential Processes (CSP) process algebra). Message-passing concurrency tends to be far easier to understand than shared-memory concurrency, and is typically considered a more robust, although slower, form of concurrent programming. Deadlocks and starvation A common problem within multiprocessing, is deadlocking and starvation. A deadlock refers to a specific condition where two or more processes are each waiting for each other to release a resource, or more than two processes are waiting for resources in a circular chain. A similar problem is starvation, where a process is perpetually denied necessary resources like CPU-cycles. Without those resources, the program can never finish its task. Back in 1965, Edsger Dijkstra set an examination question on a synchronization problem where five computers competed for access to five shared tape drive peripherals. Soon afterwards the problem was retold by Tony Hoare as the dining philosophers problem and a classic illustrative example of deadlocks and starvation was born. The culprit is normally the scheduler, who s job it is to allocate resources in a fair and equitably manner. We normally differentiate between non-preemptive and preemptive schedulers. In a non-preemptive scheduling scheme jobs are allowed to run to their completion, whereas a preemptive scheduler is based on time-slicing and clock interrupts. The JVM scheduler is for instance using a preemptive, priority based scheduling algorithm. Students and programmers should be provided with knowledge about how to spot a

24 CHAPTER 3. IDENTIFYING THE CONCEPTS 3.3. CHOOSING THE CONCEPTS deadlock, avoid starvation and consider different pragmatic coarse/fine grained locking strategies in order to illuminate the black arts of concurrency and multithreaded code [Cantrill08]. We wish to choose deadlocks and starvation as some of the concepts to be illustrated through our experiments and in particular the classical example of the dining philosophers. Teachers, who does lectures within this field, find that most students are able to understand the solutions to these problems, but few are able to produce them, or even solve similar problems [Downey08]. The learning problem these concepts exhibit, makes them ideal for the experiments Threads A thread can be defined as a single sequential flow of control within a program. There is nothing new in the concept of a single thread. The real problems arise when we want to use multiple threads in a single program all running at the same time and performing different tasks. Figure 3.1: The Life Cycle of a Thread A thread is sometimes referred to as a lightweight process. On a single processor, multithreading generally occurs by time-division multiplexing - that is the processor switches between different threads. The context switching happens frequently enough that the user perceives the threads or tasks as running at the same time. On a multiprocessor (or multi-core system), the threads or tasks can run at the same time, with each processor (or core) running a particular thread or task. Threads are by far the easiest way to tap the computing power of todays multiprocessor systems. Threads can reduce development and maintenance costs and improve the per- 21

25 3.3. CHOOSING THE CONCEPTS CHAPTER 3. IDENTIFYING THE CONCEPTS formance of complex applications. When properly designed, multithreaded programs can improve throughput by utilizing available resources more effectively [Goetz06]. Another advantage of multithreading, even for single-cpu systems, is the ability for an application to remain responsive to input. But threads also gives us many headaches [Lee06] - without explicit synchronization to coordinate access to shared data, a thread may modify variables that another thread is in the middle of using, with unpredictable results (like race conditions). So threads are considered a double-edged sword - and mainstream developers must be aware of thread-safety issues. This places a significant design and implementation burden on developers, since creating thread-safe classes require more care and analysis and the proper choice of objects and methods to synchronize is one of the more difficult things to learn about threaded programming. Finding the right balance of sequentiality and asynchrony is often characteristic of efficient people - and the same is true for programs. Even though some prefer to suggest the use of events-based programming instead [Oesterhout], threads are still widely used. We wish to choose threads, thread-safety and race conditions as some of the concepts to be illustrated through our experiments. Most non-trivial Java applications rely to some degree on threads for their organization and with the widespread acceptance of Java as an introductory programming language, many novice programmers get exposed to threads at an very early stage. Instead of ignoring this fact and leaving people on their own, it might prove a better strategy to provide them with the tools necessary to overcome those hardships Synchronization In a multithreaded environment, each thread has its own local thread stack and registers. If multiple threads access the same resource for read and write, the value may no longer be correct, the data can become corrupted and we have a data inconsistency. Different synchronization schemes guard us from these problems, but they have to be applied with care. A semaphore is a data structure that is useful for solving a variety of synchronization problems like readers/writers, producer/consumer and dining philosophers. It restricts access to a critical section and will only grant access to that section through the use of two atomic operations: wait and signal. A critical region, is a section of code that poses a problem, where several threads needs access to the same shared variable or resource. It is not necessary to use semaphores, but there are some advantages to using them: Semaphores impose deliberate constraints that help programmers avoid errors. Solutions using semaphores are often clean and organized, making it easy to 22

26 CHAPTER 3. IDENTIFYING THE CONCEPTS 3.3. CHOOSING THE CONCEPTS demonstrate their correctness. Semaphores can be implemented efficiently on many systems, so solutions that use semaphores are portable and usually efficient. A binary semaphore (a semaphore initialized to one) is sometimes referred to as a mutex. A mutex is the name for a program object that negotiates mutual exclusion among threads, also known as a lock. Java uses monitors and the synchronized keyword to control access to an object by a thread 4. Message passing Another synchronization scheme is to use message passing. Message passing is typically used within distributed systems, with no shared memory. One of the more popular schemes within message passing is the Actor Model. The rise of multi-core systems has given it a revival. It is used internally in the programming language Erlang and Scala 5 and it allows asynchronous communication. The fundamental idea behind the Actor Model is that the application is broken up into actors that perform particular roles. Every method call (or message) to an actor is executed in a unique thread, so you avoid all of the contested locking issues typically found in concurrent applications. This allows for a more efficient concurrent processing while keeping the complexity of actor implementations low (we prune away some of the non-determinism), as there is no need to consider concurrent execution within each actor implementation. This reduces concurrency issues and improves the flexibility of the system. Message passing can be used to synchronize two threads in addition to communicating data. The mutual exclusion problem arises when two threads should never simultaneously access a shared resource. An actor represents total containment, and can be accessed only by sending it a communication. The mutual exclusion problem, it can be safely asserted, is not really a problem for actors. Message passing can also be used for solving the producer/consumer synchronization problem. We wish to choose synchronization and semaphores as some of the concepts to be used in the experiments. In hindsight this was perhaps not the most obvious choice given that the later chosen computing platform (see section 4.1.4), was distributed and had no shared memory, making it somewhat cumbersome to show the use of semaphores. It seemed like a good idea at the time. Should we choose today, we would probably supplement the choice of semaphores along with message passing to show both sides of the coin

27 3.4. SUMMARY CHAPTER 3. IDENTIFYING THE CONCEPTS 3.4 Summary High Performance Computing poses many challenges including weather prediction, molecular structure models and human genome mapping. Meeting these challenges will require two things from computer scientists: an understanding of the science and an ascent to unprecedented levels of algorithmic and computational power. This poses a need to educate the students to the sciences and computation and we might as well start early to move faster up the latter of abstraction and automation. The whole idea of teaching concurrency to freshmen is not new, it s been tried a number of times [Eisentraut08]. However, teaching it within the scope of experimentation is. Programmers currently tend to solve problems by writing algorithms that are stepby-step solutions, like cake recipes, but it doesn t scale that well. Today, the new reality is that sequential, single-threaded programming is becoming obsolete for applications needing higher performance. The answer is to think parallel 6 and we might as well get used to it. This reality is seeping into the heads of software developers very slowly. Our approach is to deal with it and embrace this paradigm shift, and teach the concepts of concurrency bottom-up. Thus, we have taken a closer look at different concepts related to concurrency, threads and synchronization and chosen those upon which, we wish to base our experiments. A simplistic overview can be found in the table below: Table 3.1: Overview of chosen concepts Concept Concurrency Synchronization Threads Related concepts Non-Determinism, Deadlocks, Livelocks, Starvation Mutual Exclusion, Semaphores, Message Passing Threads-safety, Locking, Atomicity, Race conditions Concurrency can be considered a fundamental idea within computer science and as such it fulfills the four criterions: Horizontal Criterion - it s observable in a number of different areas Vertical Criterion - it can be taught at different levels of abstraction Criterion of Time - its been around since before an eternity in computer science Criterion of Sense - its related to everyday things: like when we cook a meal, we make sure that the potatoes and the meat are finished at the same time. 6 shanir/abstracts%20and%20speakers%20multicore%20programming%20education.htm 24

28 CHAPTER 3. IDENTIFYING THE CONCEPTS 3.4. SUMMARY In the following chapter we will turn our attention to the experiments and describe their layout as well as how we wish to apply the chosen concepts. We will also evaluate three different computing platforms and describe the implementation of the experiments on the platform of choice. 25

29 3.4. SUMMARY CHAPTER 3. IDENTIFYING THE CONCEPTS 26

30 Chapter 4 The Experiments 4.1 Choice of computing platform As mentioned earlier, a primary condition is to give the experiments a practical handson approach. With that requirement in mind we have evaluated three computing platforms, which could all possibly be used. We have primarily looked at different platforms within the field of sensor networks and pervasive computing. Another option could have been to look at different mobile devices, but we favored the sensor networks/pervasive platforms, because of their diversity and ability to bridge over to other fields of interest eg. meshing networks. Although both mobile devices and sensor network devices operate under the same hardware restraints (eg. small CPUs, minimal RAM and limited batteries ), the sensor network devices can be extended with a number of optional sensors which gives them an advantage. Sensor network devices are also very different from what students normally consider a computer, making it compelling and intriguing compared to their cell phone which they use every day The LEGO Mindstorms NXT platform The Mindstorms NXT platform 1 is the second generation robotics kit from LEGO. The main component in the kit is a brick-shaped computer called the NXT brick. It can take input from up to four sensors and control up to three motors, via RJ12 cables. The brick has a 100x64 pixel monochrome LCD display and four buttons that can be used to navigate a user interface using hierarchical menus. It also has a speaker and can play sound files at sampling rates up to 8 khz. Power is supplied by 6 AA batteries in the consumer version of the kit and by a Li-Ion rechargeable battery and charger in the educational version. Indside the NXT brick is a 32-bit ARM7 chip which operates at 48 MHz with 256 KiB

31 4.1. CHOICE OF COMPUTING PLATFORM CHAPTER 4. THE EXPERIMENTS flash memory and 64 KiB RAM. It uses bluetooth to transfer programs wirelessly from the PC to the robot. Lego has released the firmware for the NXT brick as open source and several developer kits are available, which has given room for a number of different firmware versions. Figure 4.1: LEGO Mindstorms NXT The Sentilla Perk platform The company Sentilla 2 was formerly known as MoteIV, but recently changed their name and platform. Sentillas focus is on pervasive computing applications and they sell a Pervasive Computing Kit called Perk. The kit includes: 2 JCreate pervasive computers 1 USB Gateway to connect to your PC Firmware Programming Fixture CD with Eclipse-based Sentilla IDE for Windows XP, Sample Applications, and Documentation 4 AAA Batteries Each JCreate is powered by a Texas Instruments 8 MHz MSP bit microprocessor, called the Tmote mini [Tmini07] and a TI/Chipcon CC2420 wireless transceiver. Each device runs on two AAA batteries, features an on-board tri-axis accelerometer to measure motion in three-dimensions, and have eight LEDs for user feedback. In addition, each JCreate has two standard connectors that allow a range of sensors to be

32 CHAPTER 4. THE EXPERIMENTS 4.1. CHOICE OF COMPUTING PLATFORM attached in a rapid and straightforward way without soldering, as well as an expansion connector for even greater flexibility and upgradeablity. Each JCreate is running Sentilla software based on Java ME CLDC 1.1 technology. Figure 4.2: The Sentilla Perk kit The SunSPOT platform The SunSPOT 3 is a small embedded sensor network device a little bigger than a cell phone. It was developed at the Sun Microsystems SunLabs division. The SunSPOT comes equipped with a 180 MHz 32 bit ARM9 CPU, 512 KiBs of RAM, 4 MiBs of flash, a 3.7V rechargeable lithium-ion battery, a ChipCon wireless radio and a sensor board. It s also programmable in Java ME CLDC making it easy to use for novice programmers. It runs Java on the bare Metal through the squawk java virtual machine [Squawk06]. The sensor board includes a 2G/6G 3-axis accelerometer, 8 tricolor LEDS, two momentary switches, a light and temperature sensor and 6 analog inputs, 5 general purpose I/O pins and 4 high current output pins. Its possible to unplug the sensor board, and switch to other available sensor boards. Its also sold as a kit including: 2 free ranging SunSPOTs including the edemo sensor board and rechargeable batteries 1 base station including the wireless radio 2 mounting brackets The SunSPOT SDK CD with NetBeans IDE, Sample Applications and Documentation 3 SPOT is short for Small Programmable Object Technology 29

33 4.1. CHOICE OF COMPUTING PLATFORM CHAPTER 4. THE EXPERIMENTS Figure 4.3: The SunSPOT kit Comparison of the platforms Each platform has its own strengths and weakness, but we have chosen those three specifically because they all support the Java programming platform. Java Technology is the obvious choice for three reasons: 1. Java Technology is taught as an introductory object-oriented programming language at many schools and universities. 2. Java Technology is a truly ubiquitous standard with an exceptionally large and vibrant community. 3. Java Technology currently operates at every existing computing tier (servers, desktop/laptops, cell phones) and represents the best choice to facilitate application integration across every computing tier. 4. Java Technology touches each facet of the software lifecycle with a complete set of tools and processes (Java Language for Development, Java Virtual Machines for Deployment, and Java SOA interfaces for integration and management. The target group for the LEGO Mindstorms Kit is a bit lower than the students we are aiming for, also the kit is almost solely focused on robotics which is a little out of 30

34 CHAPTER 4. THE EXPERIMENTS 4.1. CHOICE OF COMPUTING PLATFORM scope. However the sensors that can be attached to the kit and the main CPU is almost identical to the inner techniques of the SunSPOT kit and it s very easy to buy both commercially as well as for educational purposes. Combined with the possibility to change the firmware of the NXT brick makes it flexible for teaching programming for instance by using LeJos 4 - Java for LEGO Mindstorms. Also the the Squawk JVM 5 used on the SunSPOT platform has been ported 6 to the NXT brick making it possible to blend work on Mindstorms creations with the SunSPOTs. The Sentilla Perk kits is the cheapest and the youngest product of the three and unfortunately it seems to have a few first generation bugs, which is very common in a first release product. In 2008 it won the prestigeuos Duke s Choice Award for an innovative product at its launch at the US JavaOne conference. Sentilla was one of the first companies to realize the potential of changing the programming environment from C++ to Java, in order to shorten the time-to-market and attract more developers to the field of sensor networking and pervasive computing. Its one of the smallest Java ME compatible platforms available and the software runs within the Sentilla JVM on the JCreates. In fact, its so small that our main concern is whether it would be able to hold the experiments in main memory. Table 4.1: Comparison of the platforms on specifications Product Name: Lego NXT Mindstorms Sentilla Perk SunSPOT Chip: ARM 7 TI MSP 430 ARM 9 Speed: 48 MHz 8 MHz 180 MHz RAM: 64 KiB 10 KiB 512 KiB Flash: 256 KiB 48 KiB 4 MiB Radio: Bluetooth ChipCon 2420 ChipCon 2420 Price: 500 USD 199 USD 750 USD The SunSPOT platform is, at first glance, the most expensive of the three, but its being sold at half price for educational purposes in class sets of 15 kits, which brings the price down in a more affordable range. Its also the most powerful device in terms of computing power. One of its main goals is to make room for exploratory programming. It was first introduced to the public in 2005, but wasn t commercially available in most countries until late The SunSPOT platform is Open Source all the way, from the hardware to the software, and its gained a fairly big group of devoted developers 7. It has a vibrant community where its very easy to get help. Its also under continuos development, and its fifth firmware version has recently been pushed into beta

35 4.2. DESIGN OF THE EXPERIMENTS CHAPTER 4. THE EXPERIMENTS Several other daughter boards are also available, like the PlaySIM board and the egsm board, which is an experimental development platform that enables a SunSPOT to emulate a SIM card 8. Another board under development, is the eflash, which is a stackable add-on board for the Sun SPOT project, used for data logging 9. We have decided to use the SunSPOT platform for the experiments. The decision is primarily based on its computing power which makes it ideal for novice programmers, but also on its availability and the fact that it has proved its resilience in a constantly changing market. A choice has been made not to include any extra sensors, this has been done primarily to keep the cost of the experiments down. Getting the funding to buy a class set of 15 SunSPOT kits will probably be hard enough. Extra sensors could have been bought, but the on-board sensors covered our needs for these specific experiments. Also, not adding extra sensors meant that no soldering was required and that the SunSPOTs are easier to handle and the chance of one breaking down is smaller. 4.2 Design of the experiments With a framework for the concepts and a platform in place, we can now turn to the actual design of the experiments. The primary goal for the experiments are for them to be engaging and motivating for the students, but still with a distinct educational output. We do not believe the experiments can stand alone, so they will need to be supported by an actual lesson introducing the concepts used in the experiment. An overview of the educational lesson plan can be found on page 36. An overview of the slides needed for the lessons can be found in the Appendix B. Selecting the order in which to present the different subjects was a bit of a gothic knot, since most of the concepts are highly intertwined and we needed some sort of starting point, a stepping stone, from which to build the knowledge. However we ended up with the following workable presentation order: 1. Introduction to the SunSPOT platform 2. Introduction to threads and thread-safety 3. Introduction to synchronization and binary semaphores 4. Introduction to deadlocks and starvation

36 CHAPTER 4. THE EXPERIMENTS 4.2. DESIGN OF THE EXPERIMENTS We start out by presenting the platform, and waving a carrot in front of the students by showing them a number of compelling demonstrations of what they can actually do with this specific computing platform. The lesson is followed by a normal lab-exercise based on the existing SunSPOT Tutorial 10, in which they are asked to setup the development environment on their own laptops and run a couple of the demonstration programs themselves. We do this in order for the student to familiarize themselves with the programming environment Experiment 1: The Elevators Our first experiment introduces a race condition in terms of threads and thread-safety to the students and in particular what happens if you don t consider thread-safety. The experiment is based on a real-world example in which each SunSPOT represents an elevator. Using the on-board accelerometer, it is possible for the students to move the SunSPOTs up and down in the air and the acceleration is mapped to the eight LEDs, showing which floor the elevator (SunSPOT) is currently on. A Host-application will also be running on the student laptop, showing an elevator call button. The button is supposed to call the nearest elevator to the ground floor. The students are asked to describe what happens when you press the button. They are also asked to consider whether the program is thread-safe - whether it works correctly. The implementation is flawed with a race condition on purpose to give the students an AHA insight experience. Our hope is, that the incorrect computation will puzzle them and help in the understanding of the concept of a race condition and embed them in a discussion about how to remedy the problem. The experiment text given to the students can be found in Appendix A Experiment 2: Lock that door Our second experiment introduces mutual exclusion through the use of binary semaphores and a multiplex - a counting semaphore. The experiment is based on a real-world example in which each SunSPOT represents an airplane toilet as a shared resource, which

37 4.2. DESIGN OF THE EXPERIMENTS CHAPTER 4. THE EXPERIMENTS can only be occupied by a single thread (a person) at a time. Once you press the left button on the SunSPOT the door is locked (wait/acquire) and when you press it again you unlock the toilet (signal/release). The SunSPOT LEDs will show whether the toilet is in a locked state or not, by showing a red row of LEDs when it is locked. The placement of the LEDs and switches on the SunSPOT can be seen in the figure below: Figure 4.4: A SunSPOT with the lid removed The second part of the experiment shows what happens when you introduce a pool of shared resources with a maximum capacity. In this case, only three toilets can be used at the same time, but four toilets are in fact available. A Host-application will be running on the student laptop to coordinate the use of the shared resources. Again the students are asked to describe what happens in the program by trying it out and watching the output Experiment 3: The Twittering Computer Scientists Our third experiment introduces deadlocks and starvation through a rewrite of the classical synchronization problem - The dining philosophers 11. However in this case it is twittering computer scientists which sit around a table with only half a keyboard between them. Each SunSPOT represent a computer scientist and by pressing the two buttons on the SunSPOT he can pick up either half of the keyboard, if they are available. The leftmost and rightmost LED on the SunSPOT will show whether the keyboard half is available. If he obtains both halves of the keyboard, he will send a message to and then release both keyboard halves. The students are then asked to consider what happens if all the computer scientists start out by picking up the left half and sit around waiting for the right half to be available. Hopefully they quickly realize that they have a deadlock. They are then asked to come up with a solution that can guarantee that all computer scientists get to twitter at some point, so a solution which is deadlock and starvation free philosophers problem 34

38 CHAPTER 4. THE EXPERIMENTS 4.2. DESIGN OF THE EXPERIMENTS Design choices All the experiments have been designed - on purpose, in a way, that does not require the students to have any prior programming experience. They are designed to make the student interact with the experiment, but most importantly reflect on the knowledge given in the prior lesson and combine it with their existing knowledge. If using the experiments with more experienced computer science students, it is quite possible to change the level of difficulty by for instance asking the students to change the code or to implement their solution to fx. the twittering computer scientist problem. However, it will require an extension of the first lesson, with a requirement that the students are already familiar with the Java programming language and a walkthrough of the SunSPOT developers guide [Owner08]. Another possibility is to extend the lesson plan with a programming assignment, but we will leave that decision to the teacher, depending on the skill level of the students. We do believe that the experiment framework could also successfully be used in connection with an introductory Java class, although with a completely different set of experiments. We substantiate this claim with the success of the CS1 classes in Canada, which used the BlackBerry device The academic lesson plan At the following page, we have included the finalized lesson plan. The plan is divided into 4 double lessons (2 x 45 minutes), each starting out with an ordinary lecture introducing the concepts, followed by an hour of experimentation. We have also suggested a little supplementary home work in the form of reading material, to be read in advance. Upon completing the lesson plan the students should at least be able to: Understand some of the abstract concepts involved in concurrency, threads and synchronization Understand some of the requirements for programming concurrent systems Have some basic knowledge on synchronization methods and threads Should the teacher wish to go any further in depth with the proposed subjects and experiments and extend the lesson plan to include more lessons, we would recommend a fifth lesson about barriers and turnstiles. An introduction to barriers and turnstiles would allow the students to reflect on the knowledge and broaden the understanding of the concepts in the previous lessons. Another option could be to include an experiment based on message passing. 35

39 Educational Lesson Plan Date Description #1 Lecture 1: Introduction to the SunSPOT platform Exercise: Getting Started and setting up the development environment on your laptop Read: Installation Instructions, SunSPOT Tutorial #2 Lecture 2: Introduction to threads and thread-safety in java Experiment 1: The elevators Read: Introduction to java threads or #3 Lecture 3: Introduction to synchronization and binary semaphores Experiment 2: Lock that door Read: Allen B. Downey: Little Book of Semaphores, p #4 Lecture 4: Introduction to deadlocks and starvation Experiment 3: The twittering Computer Scientists Read: Allen B. Downey: Little Book of Semaphores, p Each Lecture consists of a set of slides and corresponding talking points for the teacher to use Each Experiment consists of a description of a task given to the students and a 5 minute introduction to the experiment to be given by the teacher. There is also a solution for the teacher. The Read-section of the educational plan is meant as home work for the students to give them an initial understanding of the concepts being taught. Each class consists of 2 x 45 minutes, split in the following manner: Hour 1: The lecture is set as minutes of presentation given by the teacher. Hour 2: The experiment is set as 30 minutes with a small introduction (5 minutes) given by the teacher, upon which the students get to work in small groups of 3 persons, followed up by a wrap-up (10 minutes) by students and teacher discussing the results. Upon completing this lesson plan the students should be able to: Understand some of the requirements for programming concurrent systems Basic knowledge on synchronization methods and threads Understand some of the abstract concepts involved in concurrency and synchronization

40 CHAPTER 4. THE EXPERIMENTS 4.3. IMPLEMENTING THE EXPERIMENTS 4.3 Implementing the Experiments The free ranging SunSPOTs comes equipped with the edemo daugtherboard 12, which contains an Atmega88 processor, flash memory, a light sensor, a temperature sensor, an accelerometer, eight tri-color LEDs and two switches. The Atmel Atmega88 microcontroller communicates with the main board ARM9 over the SPI channel as a slave device. We only use a selection of the sensors for our experiments. In the following section we will describe the sensors used in the experiments, that is - the LEDs, the switches, the accelerometer and the wireless radio LEDs and switches There are eight three-color LEDs on the demo sensor board, in a row, with LED1 on the left and LED8 on the right. Each LED has a red, a green, and a blue emitter as part of the LED. Each individual color can have an intensity from 0 to 255, with 0 being off and 255 being as bright as possible. Colors are specified with the setrgb(int red, int green, int blue) method. To use the LEDs you need to instantiate the LED object array: Import com. sun. spot. sensorboard. EDemoBoard ; Import com. sun. spot. sensorboard. ITriColorLED ; ITriColorLED [ ] ourleds = EDemoBoard. g e t I n s t a n c e ( ). getleds ( ) ; You can query the state of the LEDs using the ison() method. The LEDs can either be turned on or off using the seton() or setoff() methods. We use the LEDs in all our experiments, since it s an easy way to get definite visible feedback, due to the lack of a screen. Written feedback is provided through printf statements, which are viewable when the SunSPOT is connected to the laptop via the USB cable. Below the LEDs are two tactile momentary open pushbuttons, SW1 and SW2. To use the switches you need to instantiate the ISwitch object array: Import com. sun. spot. sensorboard. EDemoBoard ; Import com. sun. spot. sensorboard. ISwitch ; ISwitch [ ] ourswitches = EDemoBoard. g e t I n s t a n c e ( ). getswitches ( ) ; You may query the state of the switches using the isopen() and isclosed() methods. In Experiment 2 we have implemented an event loop which checks the switches in our application on a periodic basis using the waitforchange() method

41 4.3. IMPLEMENTING THE EXPERIMENTS CHAPTER 4. THE EXPERIMENTS Figure 4.5: The SunSPOT LED layout The accelerometer The edemo board contains the ST Microsystems 3-Axis 2g/6g Inertial Sensor. The orientation of the different axis, can be found in the figure below. For each axis, the maximum sample rate is 160hz. Figure 4.6: The SunSPOT accelerometer To use the accelerometer: import com. sun. spot. sensorboard. EDemoBoard ; import com. sun. spot. sensorboard. IAccelerometer3d ; IAccelerometer3D acc = EdemoBoard. g e t I n s t a n c e ( ). getaccelerometer ( ) ; To get a reading from the accelerometer one might use the getaccelx(), getaccely(), getaccelz() or getaccel() methods. The readings will be in g-force units. Another set of methods, getrelativeaccelx(), getrelativeaccely(), getrelativeaccelz() and getrelativeaccel(), return the current acceleration relative to a previously measured acceleration. This allows one to zero out the force of gravity on the SPOT and measure the relative acceleration only [Accel07]. Its also possible to measure the inclination, or tilt, of that axis with respect to the total acceleration the SPOT is experiencing. If the SPOT is at rest then the tilt is measured with respect to gravity. 38

42 CHAPTER 4. THE EXPERIMENTS 4.3. IMPLEMENTING THE EXPERIMENTS We use the accelerometer in Experiment 1, where we map the force of the Y-axis to the LEDs to show which level the elevator is currently on Radio communication The wireless network communications uses an integrated radio transceiver, the TI CC2420 (formerly ChipCon). The CC2420 is IEEE compliant and operates in the 2.4GHz to GHz ISM unlicensed bands [Theory08]. Several interfaces are provided for the radio most prominently the RadioStreamConnection and the RadiogramConnection, where the stream oriented connection provides a socket-like peer-to-peer radio protocol with reliable, buffered stream-based IO between two devices (TCP-like) and the datagram connection provides either a point-to-point connection or a broadcast mode with no delivery guarantees (UDP-like). An overview of the SunSPOT network stack can be seen in the figure below [GSN09]: Figure 4.7: Different network stacks The LoWPAN and Ad hoc On-Demand Distance Vector (AODV) Routing protocols 13 are essential parts of the SunSPOT network stack, allowing easy access to multihop routing in ad hoc mesh networks. However our usage of the network stack is limited to the application layer, where we use both radiostream and radiogram based communication in all our experiments. The broadcast mode is used from the host application using the base station to establish the correct number of client SunSPOTs when starting the application. The free ranging SunSPOTs who respond to the alive-ping are mapped into an array combining the SunSPOTs IEEE MAC-address with a corresponding port number for later usage. To open a radiogram broadcast connection and send a message, you call the following:

43 4.3. IMPLEMENTING THE EXPERIMENTS CHAPTER 4. THE EXPERIMENTS import javax. microedition. io. Connector ; import javax. microedition. io. Datagram ; import javax. microedition. io. DatagramConnection ; import com. sun. spot. i o. j2me. radiogram. RadiogramConnection ; dgbconn = ( DatagramConnection ) Connector. open ( radiogram :// broadcast : 3 7 ) ;... Datagram dg = dgbconn. newdatagram ( dgbconn. getmaximumlength ( ) ) ; dg. writeutf (m) ; dgbconn. send ( dg ) ; Afterwards only the stream oriented radio connection is used, to guarantee that we don t loose any packets, which would cripple the functionality of the experiments. To open a radio stream connection and send a message, you call the following: import javax. microedition. io. Connector ; import com. sun. spot. i o. j2me. radiostream. RadiostreamConnection ; import java. io. DataOutputStream ; StreamConnection conn = ( StreamConnection ) Connector. open ( radiostream ://nnnn. nnnn. nnnn. nnnn : xxx ) ;... out = ( DataOutputStream ) conn. opendataoutputstream ( ) ;.... out. writeutf (msg ) ; out. f l u s h ( ) ; Where nnnn.nnnn.nnnn.nnnn is the 64-bit IEEE address of the radio, and xxx is a unique port number. To establish a connection both ends must open connections specifying the same port number, which is why we needed to start the experiment by making a list of the active clients. The radio communication in Experiment 2, between the host and spot application, can be described with the following two network communication diagrams: Figure 4.8: Experiment 2 network communication The host application is necessary, because semaphores only works within shared 40

44 CHAPTER 4. THE EXPERIMENTS 4.3. IMPLEMENTING THE EXPERIMENTS memory, but we do not have shared memory across the distributed SunSPOTs. The host application takes the role of the coordinator of the shared resources and controls the access to the pool of resources. Another problem is, that the module java.util.concurrent is not available for Java ME, so the Semaphore class, is not at all available on the SunSPOTs. On the host application we can run Java SE programs, which allows us access to the extended Java API, thus solving the problem. The radio communication in Experiment 3, between host and client application is a little more complicated as it requires more book keeping. In Experiment 3, the host application is also used as a coordinator to keep track of the current state of the experiment. That includes a communication scheme where each SunSPOT tells the host-application through a radio message, when a button has been pushed (a keyboard-part taken or released) and its the job of the host-application to notify the neighbor SunSPOTs of the changed state, so they can turn the necessary LEDs on/off. The ordering of the neighboring computer scientists correspond to the ArrayList of all the SunSPOT clients and their port numbers, which means we have to take into account when a SunSPOT might be the last spot in the array or the first spot in the array to find the correct neighbor. The resulting flowchart of the internal states of the host-application can be viewed in Figure 4.9. We parse the received message with respect to the two first words, which can be either LEFT/RIGHT and taken/free - with respect to LEFT keyboard taken or RIGHT keyboard free. The chart for the free-states have been left out of the flowchart for simplicity, since they are similar to the taken-states, except for the LEDs to be turned on instead of off. It makes perfect sense design-wise to leave the extra work up to the host-application. The host-application is run on a laptop, which computing-wise is several magnitudes faster than the SunSPOT. So by making the host-application take on the extra work, we can simplify and thus speed-up the program on the SunSPOTs themselves, making the experiment more responsive The Squawk virtual machine The Squawk virtual machine is a Java VM primarily written in Java. It translates standard class files into an internal pre-linked, position independent format (.suite) that is compact and allows for efficient execution of bytecodes that have been placed into a read-only memory. Squawk was designed solely for use on memory restrained devices and is compliant with the Connected Limited Device Configuration (CLDC) 1.1 Java Micro Edition. It runs without the need for an underlying operating system, which leaves space for the developer on the sparse memory of the device. Resource constrained devices does not have enough space to implement class file loading on the device, so a split VM architecture is used. Figure 4.10 shows the split ar- 41

45 4.3. IMPLEMENTING THE EXPERIMENTS CHAPTER 4. THE EXPERIMENTS RECEIVED MSG free SECOND WORD? LEFT FIRST WORD? RIGHT SECOND WORD? free taken TWEET: taken Send msg to LEFT neighbor to turn RIGHT LED OFF NO First spot in array? Call posttwitterupdate and send messge to LEFT and RIGHT neighbors to turn LEDs on Last spot in array? NO Send msg to RIGHT neighbor to turn LEFT LED OFF YES YES Send msg to LAST spot in array to turn RIGHT LED OFF Send msg to FIRST spot in array to turn LEFT LED OFF Figure 4.9: Flowchart of the internal states of the Experiment 3 host-program chitecture, with the class file preprocessor, called the suite creator, to the left and the on-device VM to the right. The green shaded parts of the on-device VM, are the only parts of the VM written in C. In Squawk, each application is represented by a Java object. This object is an instance of the class Isolate. Isolates are analogous to processes in an operating system - each Isolate has resources that are shared amongst the threads of that Isolate. In Squawk the immutable state of an Isolate is shared. The VM is always executing in the context of a single current Isolate object. Each application is given the illusion of running in its own isolated virtual machine and they each have their own system properties. There are two primary motivations behind this. One is to prevent the faults within an application from propagating to other applications. It prevents two applications from interfering with each other. The other is to ensure that an Isolate can be terminated. An Isolate has a halt() method that unlike the Thread.stop() method causes all the threads within the Isolate to stop and keep the state consistent. The Isolate controlling the SunSPOT at the system level is the master Isolate. There is only one master Isolate per SPOT. The master Isolate controls the radio stack for the SPOT and access to the other components of the SPOT. Normally a SunSPOT application consists of a single Java ME MIDlet that is run in the master Isolate, however several MIDlets can be packaged into a single.jar file. All SPOT applications conform 42

46 CHAPTER 4. THE EXPERIMENTS 4.3. IMPLEMENTING THE EXPERIMENTS Figure 4.10: Overview of the split VM Figure 4.11: Overview of the Isolate mechanism to the MIDlet standard. That is, all applications implement the three members start- App(), pauseapp() and destroyapp(). Being a bare metal VM, Squawk implements green threads. Green threads emulate multi-threaded environments without relying on any native operating system capabilities. They run code in user space that manages and schedules threads Threading We use Java threading and synchronization throughout the Experiments, especially during radio communication to ensure that we aren t interrupted during the send and receive calls. That is, we use the same thread-safety tools in the code, that the students 43

47 4.4. SUMMARY CHAPTER 4. THE EXPERIMENTS are asked to comprehend. In Java each thread is associated with an instance of the class Thread. We can easily create and start new threads like the following, where we create a thread to watch the push of a button: public void startsw1watchthread ( ) { new Thread ( ) { public void run ( ) { while ( true ){ sw1. waitforchange ( ) ; i f ( sw1. isclosed ( ) ) { sw1closed ( ) ; e l s e { sw1opened ( ) ;. s t a r t ( ) ; Threads can also be put to sleep with the call Thread.sleep() which is in fact the same as a call to Utils.sleep(). Its up to the Java scheduler to decide which threads to run based on their priority. One can in fact set a thread priority, but its not considered a good idea, since priority schemes are very different between operating systems, leaving the code to be unpredictable if changing platforms. 4.4 Summary In this chapter we have evaluated three different platforms - and chosen the one we felt was the most robust in terms of computing and software: the SunSPOT platform. The chosen platform fulfill our Chapter 2 hands-on requirement and allow the student to be an active participant in the experiment and not just a passive observer forced to reflect, like in traditional class-based teaching. We had at our disposal two SunSPOT kits, for the development, which allowed us to use four physical free ranging SunSPOTs. We have designed three different experiments based on the Chapter 3 chosen computer science concepts to fulfill our own requirement about experiment content and we have based the experiments on real-world examples. We do believe that the experiments will not dumb-down the teaching of the concepts, but instead allow the students to comprehend the concepts in another way. Testing of the experiments on the chosen target group will show us whether this claim is true. We have also prepared a corresponding lesson plan with teaching materials, to fulfill our requirement about enriching the experience, which can be viewed in Appendix 44

48 CHAPTER 4. THE EXPERIMENTS 4.4. SUMMARY B. Last but not least we have described the implementation details for the experiments on the selected platform of choice. Two out of the three experiments were implemented within the given time. The third and last experiment (the elevators) was not fully implemented at the time of writing. In the following chapter we will turn towards testing and evaluating the implemented experiments. 45

49 4.4. SUMMARY CHAPTER 4. THE EXPERIMENTS 46

50 Chapter 5 Test and evaluation In order to test and evaluate the produced teaching materials and experiments we ve setup and performed a thinking aloud (TA) test [Chi97] with a group of three test subjects 1. The main benefit of the thinking aloud test, is a better understanding of the user s mental model and interaction with the experiment. The purpose of the method is to make explicit what is implicitly present in subjects who are able to perform a specific task. The test subjects were given one of the experiments to solve as a group, and asked to vocalize their thoughts to each other while working on the experiment. They were videotaped during the test to capture their conversation as well as their expressions. The three test subjects were 2 HTX 2 students (SB1 and SB2), who just finished their final exams and one first year DIKU student (SB3), who just finalized his first year at the university. These three test subjects were chosen, because they fit within our target group for the experiments. All test subjects were male. We would have preferred to have mixed sex test subjects, but it was unfortunately not possible. The test was conducted over a period of 4 hours on the 24th of June. Due to a timing constraints 3 we couldn t test all the experiments, instead a single experiment was chosen (Experiment 3). In order to give a proper introduction to the experimentation the following plan was used for the test: 1. hour: General introduction to the SunSPOT platform (Lesson 1) 2. hour: Introduction to the experiment (Lesson 4) 3. hour: Experiment 3 - The Twittering Computer Scientists (hands-on) 1 hci.html 2 HTX - Higher Technical Examination Programme. The programme gives special attention to scientific, technical and communicative subjects. Its equivalent to gymnasiums and high schools 3 It was exceptionally difficult to find willing test subjects in the middle of summer exams! 47

51 5.1. RESULTS CHAPTER 5. TEST AND EVALUATION 4. hour: Small-talk The experiment-part and the Small-talk part was videotaped and transcriptions from both can be found in Appendix D. 5.1 Results The experiment was a huge success. The test subjects spent a little more than an hour on the experiment, and could easily have continued if they hadn t been stopped. They were very eager and motivated after the initial introduction to the platform, where they also got to work/play with a number of default demonstration programs (Bouncing Ectoplasmic Ball, Airtext and a Telemetry Demo). Even though it was very hot and in the afternoon they stayed focused on the experiment and tried out several strategies for deadlock-free algorithms, in which process they reset the experiment 3 times, to unplug and re-plug a SunSPOT in order to test the difference with an even or odd number of SunSPOTs. When asked afterwards during the reflection phase (small-talk) how they felt about the experiment one of the test subjects (SB3) enthusiastically proclaimed that this was the most-fun labs-exercise he had ever tried! This was supported by the fact, that several times during our small-talk after the experiment their fingers went for the SunSPOTs on the table, just to push the buttons one or two times more. When asked, the test subjects expressed that they were ready to proceed to implementing the found algorithm. SB2 was also hooked on more embedded development and later asked a friend (the one recording the video), if he could use his LEGO Mindstorms NXT kit for a summer project. The last (SB1) was ready to take one of the SunSPOTs home and continue working with them. Test subject SB3 also installed the entire development environment on his laptop and started looking into the Solarium Virtual SPOT emulator 4, where it is possible to test and deploy programs to any number of virtual SunSPOTs [Solarium08]. A couple of times it was obvious, that they struggled with the perception and understanding of deadlocks, and they kept going back to confirm their findings once in a while during the experiment. In real-life, an exam question or similar methodical test could have determined whether the test subjects had the correct perception of the concepts. At another point they got stuck with one strategy for their algorithm, and the instructor had to step in and help out with a minor indication, but this was only to be expected. It was also obvious that the DIKU student (SB3) had an advantage due to a better technical language with the proper domain terminology, which allowed him to be more

52 CHAPTER 5. TEST AND EVALUATION 5.1. RESULTS Figure 5.1: The Solarium SPOT emulator verbose and take more control than the other test subjects. When asked afterwards, how they felt about talking aloud during the experiment, they claimed that it came naturally as part of working as a team. An interesting observation was how they interacted with the experiment. They never took one look at the actual code, and they hardly looked at the written output, at the laptop. Instead they used the simple feedback of the LEDs and used the buttons to manipulate the state of the experiment. Once in a while they checked the twitterhomepage to confirm their findings. In other words they chose a purely enactive mode of representation, which allowed them to turn the primary focus to the understanding of the concepts. 49

53 5.1. RESULTS CHAPTER 5. TEST AND EVALUATION 50

54 Chapter 6 Conclusion In this thesis we have reviewed a number of different learning theories, described a number of teaching examples and proposed a renewal of the teaching methods using experimentation. We have analyzed a number of computer science concepts, which are considered hard to grasp, and fully implemented two out of three outlined experiments based on these concepts. The proposed concepts, experiments and corresponding teaching materials are to be used in a pre-college computer science curriculum. Furthermore we have tested the experiments and the teaching materials and found that it is in fact a fully functional and very motivating teaching method increasing the students technical curiosity. The experiments were a success. It is our belief based on the conducted test and the following reflection, that the teaching method of experimentation did increase the overall motivation and active participation of the students. In fact the time scheduled for the experiment, might be a little too short (at least for Experiment 3) to allow them to fully interact and try out several strategies. Since it was the students first encounter with the taught concepts, it was not possible for us to establish the students depth of concept understanding, but watching them interact with the experiment gave the impression that they did establish proper mental models representing the concepts. The full picture would have been uncovered by a formal specialized test like the Concept Inventory, but that was beyond the scope of this thesis. A very interesting observation was how they interacted with each other during the experiment. The discussions they had were conceptualized and at no point during the experiment, did they look at the code. That tells us, that the experiments is in fact an excellent way to teach concepts, as it allows the students to discuss the concepts within a understandable context and move up the latter of abstraction instead of down. The switched focus away from the tools and toward the concepts was rewarding. 51

55 6.1. FUTURE WORK CHAPTER 6. CONCLUSION In the context of computational thinking this is what we were aiming for, the ability to reformulate a seemingly difficult problem into one we know how to discuss and solve. Experimentation was a suitable representation as it modeled the relevant aspects of the problem and made it tractable. It allowed the students to use both abstraction, automation and decomposition. The found results have given us a hope that it is possible to change the way we currently teach computer science. We know that Rome wasn t built in a day, and old habits die hard, but watching the students spontanous joy and their appetite for knowledge was inspiring. We know, that our contribution is but a small piece of the puzzle, but at least during the trial of the experiments, the magic and beauty of computer science had been recovered. All the experiments will be uploaded to and information will also be posted at the SunSPOT community forum under the discussion SunSPOTs in Academia 1 to spread the knowledge and allow others to use and extend the experiments. 6.1 Future Work A couple of challenges lies on the road ahead. One of these being how to spread the appropriate knowledge and know-how to the high school teachers. One possibility could be for the CS department at the local university to establish a summer workshop for the interested high school teachers who is currently teaching within the field of science, like they have done at Carnegie Mellon University 2. In Denmark, the Faculty of Science at the University of Copenhagen, held a high school teachers Inspirational Day 3 at the university in January 2009, which was a huge success with over 300 participating high school teachers. Due to its success, it will be repeated in and it would be an obvious way for the Department of Computer Science to get into contact with interested high school teachers on the lookout for new ideas for their curriculum. We participated with the SunSPOTs in the 2009 edition of the Inspirational Day (before we had the finalized experiments), and talked to about 30 high school science teachers during one of the workshops. They were all very interested in the SunSPOT platform, however they had three reasons for not using them in classes: 1. it would require funding on the verge of what was believed possible

56 CHAPTER 6. CONCLUSION 6.1. FUTURE WORK 2. they didn t feel they had the immediate knowledge to teach it 3. they felt unsure as to maintain the necessary development environment. - all very plausible obstacles that has to be overcome. One possibility is to integrate the use of the Solarium virtual spot emulator into the experiments, this would reduce the costs for equipment, but it would also mean the removal of some of the hands-on approach, since one would no longer be able to work physically with the hardware, which might have a negative effect on the whole experience. Another possibility is to simply buy fewer kits, and set the base station into shared mode (a normal spot can work as a base station too). This would allow the coexistence of the physical spots along with the virtual spots reducing the overall number of necessary spots. As for the teachers gaining the appropriate knowledge - we have taken contact to the chairman of the Danish computing association for high school teachers 4 and we will try to distribute information about the teaching materials through their web-portal. Our biggest concern is, whether they are willing to spend the extra time on preparation. The last obstacle is probably the easiest one, since most of the students today usually bring their own laptop/netbook to class. By using the students own computer, the task of maintaining the development environment no longer rests with the teacher, but is the responsibility of the student. It is our modest hope that other teachers will see the advantages of this practical teaching method and incorporate it into existing curricula. It is our firm belief that both students and academia will benefit from it and through it, and that it will enable more people to embrace the power of experimentation, problem solving and not least computational thinking

57 6.1. FUTURE WORK CHAPTER 6. CONCLUSION 54

58 Bibliography [Accel07] Using the LIS3L02AQ Accelerometer, A SunSPOT Application Note, Ron Goldman, Sun Microsystems, [Alice04] Evaluating the Effectiveness of a new Instructional Approach, Barb Moskal, Debroah Lurie and Stephen Cooper, Saint Jospeh s University and Ithaca College, [Arnold07] InfoTraffic - Teaching Important Concepts of Computer Science and Math through Real-World Examples, Ruedi Arnold, Marc Langheinrich, Werner Hartmann, ETH Zürich, ACM, [Baldwin92] Using Scientific Experiments in Early Computer Science Laboratories, Doug Baldwin and Johannes A. G. M. Koomen, ACM [Bruner60] The process of education, J.S. Bruner, Cambridge Mass [Cantrill08] Real-World Concurrency, Bryan Cantrill and Jeff Bonwick, Sun Microsystems in ACM Queue, September [Chi97] Quantifying Qualitative Analyses of Verbal Data: A Practical Guide, Michelene T. H. Chi, University of Pittsburg, The Journal of the Learning Sciences, [Developer08] SunSPOT Developers Guide, Sun Microsystems, Sun Labs, August [Downey08] Little Book of Semaphores, Allen B. Downey, Second Edition version 2.1.5, [Dysthe03] Dialog, Samspil og læring, Olga Dysthe, Klim, [Eisentraut08] Teaching Concurrency Concepts to Freshmen, Christian Eisentraut and Holger Hermanns, Saarland University, [Goetz06] Java Concurrency in Practice, Brian Goetz et al., Addison Wesley, [Goldman08] Identifying Important and Difficult Concepts in Introductory Computing Courses using a Delphi Process, Ken Goldman, Paul Gross, Cinda Heeren, Geoffrey Herman, Lisa Kaczmarczyk, Michael C. Loui, and Craig Zilles, Portland Oregon USA, SIGCSE

59 BIBLIOGRAPHY BIBLIOGRAPHY [GSN09] Overcoming a Communication Barrier on the Way Towards a Global Sensor Network, Jochen Furthmüller et al., ECEASST, Volume 17, [Hake98] Interactive-engagement versus traditional methods: A six-thousand-student survey of mechanics test data for introductory physics courses, Richard R. Hake, Journal of American Association of Physics Teachers [Knox96] Use of laboratories in Computer Science education: guidelines for good practice - Report of the Working Group on Computing Laboratories, Deborah Knox, Ursula Wolz et. al, ACM [Lee06] The Problem with Threads, Edward A. Lee, Electrical Engineering and Computer Sciences, University of Berkeley, Technical Report [Mahmoud07] Integrating BlackBerry Wireless Devices into Computer Programming and Literacy Courses, Qusay H. Mahmoud and Allan Dyer, University of Guelph, Canada, ACMSE, [Owner08] SunSPOT Owners Manual, Sun Microsystems, Sun Labs, August [Oesterhout] Why Threads Are A Bad Idea (for most purposes), John Ousterhout, Sun Microsystems Laboratories, [Papert83] Mindstorms, Children, Computers and Powerful Ideas, Seymor Papert, MIT Press, [Schwill96] Fundamental Ideas of Computer Science, Andreas Schwill, Fachbereich Mathematik/Informatik - Universität Paderborn, [Solarium08] Using the SunSPOT Emulator, Ron Goldman, Sun Microsystems, June [Squawk06] Java on the Bare Metal of Wireless Sensor Devices - The Squawk Java Virtual Machine, Doug Simon, Cristina Cifuentes, Derek White et al., Sun Microsystems, ACM, [Sutter05] The Free Lunch is Over - A Fundamental Turn Toward Concurrency in Software, Herb Sutter, Dr. Dobb s Journal, 30(3), March [Theory08] SunSPOT Theory of Operation, Sun Microsystems, Sun Labs, August [Tmini07] Tmote Mini Datasheet, Moteiv Corporation, [Wing06] Computational Thinking, Jeannette M. Wing, Viewpoint in Communications of the ACM, Vol. 49, No. 3, March

60 Appendix A Experiment descriptions A.1 Experiment 1 57

61 Experiment 1: Illustration of threads The elevators Description: Three elevators move between different floors. Each SunSPOT represent an elevator. The movement of the SunSPOT up and down maps the reading of the y-parameter of the accelerometer to a floor, which is displayed on the LEDs. Each elevator run independently of the others (its a thread) Run the example application Elevator-OnSPOT on 3 free ranging SunSPOTs. You also need to have the base station connected and run the host application Elevator-OnHost at the same time. Start the application on all free ranging SPOTs before starting the host application. Goal: Now push the elevator call button in the host application, while moving the other SunSPOTs up and down, it should call the nearest elevator. Describe what happens in the program by watching the output from both client and host application. Is the program thread-safe? Prerequisite: Lesson 2 Introduction to threads and thread-safety in Java Estimated time: minutes Equipment: 3 free ranging SunSPOTs, 1 SunSPOT base station, one laptop with Netbeans and the SunSPOT SDK.

62 APPENDIX A. EXPERIMENT DESCRIPTIONS A.2. EXPERIMENT 2 A.2 Experiment 2 59

63 Experiment 2: Illustration of a mutex Lock that door Description: When you are onboard a plane, only one person can access the toilet at a time. There is a lock on the door, to ensure this. Consider that a person equals a thread and the toilet is a shared variable. The person controls the lock (mutex) and locks (wait) the toilet when entering and unlocks (signal) the toilet when leaving. Each sunspot represent a toilet when you press the button (SW1) it locks the door, when you press the button again it unlocks the door. The LEDs show whether the door is locked or not when it shows a row of red LEDs the door is locked. Run the example application Lockthatdoor and Lockthatdoor-OnHost with one SunSPOT and the host application. Describe what happens in the program by watching the output from both client and host application. Goal: Now we wish to generalize the solution to allow multiple threads to run in the critical section at the same time, but enforce an upper limit on the number of concurrent threads. In other words there are now 3 toilets on the plane, so no more than 3 people (threads) can run in the critical section at the same time. This pattern is called a multiplex. Run the example application with 4 SunSPOTs and the host application. Describe what happens when a fourth person tries to enter the toilet? Prerequisite: Lesson 3 Introduction to synchronization and semaphores Estimated time: minutes Equipment: 4 free ranging SunSPOTs, 1 SunSPOT base station, one laptop with Netbeans and the SunSPOT SDK.

64 APPENDIX A. EXPERIMENT DESCRIPTIONS A.3. EXPERIMENT 3 A.3 Experiment 3 61

65 Experiment 3: Illustration of deadlocks and starvation The twittering Computer Scientists Description: 5 Computer Scientists are sitting around a round table, they either think or twitters about their thoughts. When twittering they need...a keyboard to type their thoughts. There is half a keyboard placed between each computer scientist and they need both halves before they can twitter. Each sunspot represent a Computer Scientist. If the right half of the keyboard is present, the rightmost yellow LED is turn on. If the left half of the keyboard is present, the leftmost yellow LED is turned on. You can at any time press SW1 and SW2 accordingly to pick up the either part of the keyboard and the SunSPOT will twitter at if you pick up both parts. After twittering it releases the two parts of the keyboard. This is a rewrite of a classic synchronization problem called Dining philosophers. Run the example application TwitteringCS-OnSPOT on 4 free ranging SunSPOTs. You also need to have the base station connected and run the host application TwitteringCS-OnHost at the same time. Start the application on all free ranging SPOTs before starting the host application. Describe what happens in the program by watching the output from both client and host application. Goal: Describe what happens if all Computer Scientist picks up the left half of the keyboard. (You can put down the keyboard half again by pressing the button again.) Try to come up with a solution to the problem which guarantees that all Computer Scientists get to twitter at some point (no deadlocks or starvation). Prerequisite: Lesson 4 Introduction to deadlocks and starvation. Estimated time: minutes Equipment: 4-5 free ranging SunSPOTs or emulated SunSPOTs, 1 SunSPOT base station, one laptop with Netbeans and the SunSPOT SDK.

66 Appendix B Lesson slides B.1 Lesson 1 63

67 Lesson 1: Introduction to the SunSPOT platform What is it? Invented at Sun Microsystems Sun Labs division in 2005/2006 SPOT is short for: SMALL PROGRAMMABLE OBJECT TECHNOLOGY Its a small computer you can use for almost anything!

68 The anatomy of a SunSPOT The device has three layers: Battery ARM based processor board with wireless radio Add-on sensor board Processor board acts as base station User programs the device in the programming language Java using the integrated development environment NetBeans It comes in a class set with 2 free ranging SunSPOTs and one base station. SunSPOT Hardware Processor board: 180 MHz 32 bit ARM920T core - 512K RAM/4M Flash 2.4 GHz ZigBee radio with integrated antenna USB interface 3.7V rechargeable 720 mah lithium-ion battery Sensor board: 2G/6G 3-axis accelerometer Light and temperature sensor 8 tri-color LEDs, 2 momentary switches 6 analog inputs, 5 general purpose I/O pins and 4 high current output pins

69 SunSPOT Software Development Kit (SDK) Squawk Java VM: Desktop and Sun SPOT Libraries: Java ME CLDC 1.1 libraries Hardware libraries SPI, AIC, TC, PIO drivers all written in the Java programming language Demo sensor board library Wireless layer libraries Network layer libraries MAC layer written in Java Desktop libraries What is Squawk? Another Sun Labs project A java virtual machine written in java Open source as of January 23rd 2008 Inspiration from Squeak, a Smalltalk environment written in Smalltalk You can find it on the net here:

70 The Squawk virtual machine A split JVM architecture