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

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

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

Contents 1 Introduction 3 1.1 Thesis problems................................. 4 1.2 Teaching experimentation........................... 4 1.3 The target group................................. 5 1.4 Contributions.................................. 5 1.5 Outline...................................... 6 2 Related Work 7 2.1 Learning theories................................ 7 2.1.1 Learning by doing........................... 8 2.1.2 Zone of proximal development.................... 9 2.1.3 Scaffolding................................ 9 2.1.4 Constructionism............................ 10 2.1.5 Experiential learning.......................... 11 2.2 Teaching examples............................... 13 2.2.1 Using the BlackBerry.......................... 13 2.2.2 Using real-world examples...................... 13 2.3 Summary..................................... 14 3 Identifying the Concepts 17 3.1 Concept Inventories............................... 17 3.2 Fundamental Ideas............................... 18 3.3 Choosing the concepts............................. 19 3.3.1 Concurrency............................... 19 3.3.2 Threads................................. 21 3.3.3 Synchronization............................. 22 3.4 Summary..................................... 24 4 The Experiments 27 4.1 Choice of computing platform......................... 27 4.1.1 The LEGO Mindstorms NXT platform................ 27 4.1.2 The Sentilla Perk platform....................... 28 4.1.3 The SunSPOT platform........................ 29 1

CONTENTS CONTENTS 4.1.4 Comparison of the platforms..................... 30 4.2 Design of the experiments........................... 32 4.2.1 Experiment 1: The Elevators..................... 33 4.2.2 Experiment 2: Lock that door..................... 33 4.2.3 Experiment 3: The Twittering Computer Scientists......... 34 4.2.4 Design choices............................. 35 4.2.5 The academic lesson plan....................... 35 4.3 Implementing the Experiments........................ 37 4.3.1 LEDs and switches........................... 37 4.3.2 The accelerometer........................... 38 4.3.3 Radio communication......................... 39 4.3.4 The Squawk virtual machine..................... 41 4.3.5 Threading................................ 43 4.4 Summary..................................... 44 5 Test and evaluation 47 5.1 Results...................................... 48 6 Conclusion 51 6.1 Future Work................................... 52 A Experiment descriptions 57 A.1 Experiment 1................................... 57 A.2 Experiment 2................................... 59 A.3 Experiment 3................................... 61 B Lesson slides 63 B.1 Lesson 1..................................... 63 B.2 Lesson 3..................................... 72 B.3 Lesson 4..................................... 80 C Source code 87 C.1 Experiment 2 - LockTheDoor-onSPOT Application.java.......... 87 C.2 Experiment 2 - LockTheDoor-onHost SunSpotHostApplication.java... 93 C.3 Experiment 2 - LockTheDoor-onHost SpotRadio.java........... 99 C.4 Experiment 3 - TwitteringCS-OnSPOT Application.java.......... 100 C.5 Experiment 3 - TwitteringCS-OnHost SunSpotHostApplication.java... 109 D Video transcriptions (in Danish) 119 D.1 Transcription of TA test............................. 119 D.2 Transcription of Small-talk after TA...................... 130 2

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? 1 http://www.alice.org/ 2 http://www.greenfoot.org/ 3 http://scratch.mit.edu/ 4 http://research.microsoft.com/en-us/projects/kodu/ 5 http://www.alice.org/kelleher/storytelling/ 3

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. 6 http://www.nbi.ku.dk/nyheder/nyheder 08/fra tavleundervisning til eksperimenter/ 4

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. 7 http://www.freescale.com/ 5

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

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

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. 2.1.1 Learning by doing John Dewey (1859-1952) - 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

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. 2.1.2 Zone of proximal development Another dominant socio-culturalist was Lev Vygotsky (1896-1934). 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. 2.1.3 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

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. 2.1.4 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 (1896-1980) 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

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 1998. 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. 2.1.5 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: 1 http://el.media.mit.edu/logo-foundation/index.html 2 http://www.ni.com/labview/, LabVIEW is short for Laboratory Virtual Instrumentation Engineering Workbench 11

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

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. 2.2.1 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. 2.2.2 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 http://java.sun.com/developer/technicalarticles/interviews/community/mahmoud qa.html 13

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 4 http://people.inf.ethz.ch/rarnold/infotraffic/index.html 5 http://www.experimentarium.dk/ 6 http://www.danfossuniverse.com/ 7 http://www.universeresearchlab.com/page3101.aspx 14

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

2.3. SUMMARY CHAPTER 2. RELATED WORK 16

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 - http://www.dun-net.dk/media/58711/2006 01 F.pdf 17

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

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

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 2 http://erlang.org/ 3 http://www.wotug.org/occam/ 20

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

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

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. 4 http://www.javaworld.com/javaworld/jw-10-1998/jw-10-toolbox.html 5 http://www.scala-lang.org/ 23

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 1965 - 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 http://www.cs.tau.ac.il/ shanir/abstracts%20and%20speakers%20multicore%20programming%20education.htm 24

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

3.4. SUMMARY CHAPTER 3. IDENTIFYING THE CONCEPTS 26

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. 4.1.1 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 1 http://mindstorms.lego.com/ 27

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 4.1.2 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 MSP430 16 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 2 http://www.sentilla.com/ 28

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 4.1.3 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

4.1. CHOICE OF COMPUTING PLATFORM CHAPTER 4. THE EXPERIMENTS Figure 4.3: The SunSPOT kit 4.1.4 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

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 2007. 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. 4 http://lejos.sourceforge.net/ 5 http://research.sun.com/projects/squawk/index.html 6 https://nxtsquawk.dev.java.net/ 7 http://www.sunspotworld.com/ 31

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 8 https://playsim.dev.java.net/ 9 https://spot-eflash.dev.java.net/ 32

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. 4.2.1 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. 4.2.2 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 10 http://www.sunspotworld.com/tutorial/hwtutorial.html 33

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. 4.2.3 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 http://twitter.com/sunspotdemo 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. 11 http://en.wikipedia.org/wiki/dining philosophers problem 34

CHAPTER 4. THE EXPERIMENTS 4.2. DESIGN OF THE EXPERIMENTS 4.2.4 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. 4.2.5 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

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: http://www.javaworld.com/javaworld/jw-04-1996/jw-04-threads.html Introduction to java threads or http://java.sun.com/docs/books/tutorial/essential/concurrency/ #3 Lecture 3: Introduction to synchronization and binary semaphores Experiment 2: Lock that door Read: Allen B. Downey: Little Book of Semaphores, p. 1 20 #4 Lecture 4: Introduction to deadlocks and starvation Experiment 3: The twittering Computer Scientists Read: Allen B. Downey: Little Book of Semaphores, p. 93 106 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 30-45 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

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. 4.3.1 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. 12 https://spot-edemo.dev.java.net/ 37

4.3. IMPLEMENTING THE EXPERIMENTS CHAPTER 4. THE EXPERIMENTS Figure 4.5: The SunSPOT LED layout 4.3.2 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

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. 4.3.3 Radio communication The wireless network communications uses an integrated radio transceiver, the TI CC2420 (formerly ChipCon). The CC2420 is IEEE 802.15.4 compliant and operates in the 2.4GHz to 2.4835GHz 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: 13 http://www.ietf.org/rfc/rfc3561.txt 39

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

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

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

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

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

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

4.4. SUMMARY CHAPTER 4. THE EXPERIMENTS 46

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 http://www.useit.com/papers/guerrilla 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

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 4 http://www.sunspotworld.com/tutorial/tutorial2.html 48

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

5.1. RESULTS CHAPTER 5. TEST AND EVALUATION 50

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

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 https://spots-curriculum.dev.java.net/ 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 2010 - 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 1 https://www.sunspotworld.com/forums 2 http://www.cs.cmu.edu/cs4hs/summer09/overview.html 3 http://www.science.ku.dk/inspirationsdag/ 52

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. 4 http://www.emu.dk/gym/fag/dl/ 53

6.1. FUTURE WORK CHAPTER 6. CONCLUSION 54

Bibliography [Accel07] Using the LIS3L02AQ Accelerometer, A SunSPOT Application Note, Ron Goldman, Sun Microsystems, 2007. [Alice04] Evaluating the Effectiveness of a new Instructional Approach, Barb Moskal, Debroah Lurie and Stephen Cooper, Saint Jospeh s University and Ithaca College, 2004. [Arnold07] InfoTraffic - Teaching Important Concepts of Computer Science and Math through Real-World Examples, Ruedi Arnold, Marc Langheinrich, Werner Hartmann, ETH Zürich, ACM, 2007. [Baldwin92] Using Scientific Experiments in Early Computer Science Laboratories, Doug Baldwin and Johannes A. G. M. Koomen, ACM 1992. [Bruner60] The process of education, J.S. Bruner, Cambridge Mass. 1960. [Cantrill08] Real-World Concurrency, Bryan Cantrill and Jeff Bonwick, Sun Microsystems in ACM Queue, September 2008. [Chi97] Quantifying Qualitative Analyses of Verbal Data: A Practical Guide, Michelene T. H. Chi, University of Pittsburg, The Journal of the Learning Sciences, 1997. [Developer08] SunSPOT Developers Guide, Sun Microsystems, Sun Labs, August 2008. [Downey08] Little Book of Semaphores, Allen B. Downey, Second Edition version 2.1.5, 2008. [Dysthe03] Dialog, Samspil og læring, Olga Dysthe, Klim, 2003. [Eisentraut08] Teaching Concurrency Concepts to Freshmen, Christian Eisentraut and Holger Hermanns, Saarland University, 2008. [Goetz06] Java Concurrency in Practice, Brian Goetz et al., Addison Wesley, 2006. [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 2008. 55

BIBLIOGRAPHY BIBLIOGRAPHY [GSN09] Overcoming a Communication Barrier on the Way Towards a Global Sensor Network, Jochen Furthmüller et al., ECEASST, Volume 17, 2009. [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 1998. [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 1996. [Lee06] The Problem with Threads, Edward A. Lee, Electrical Engineering and Computer Sciences, University of Berkeley, Technical Report 2006. [Mahmoud07] Integrating BlackBerry Wireless Devices into Computer Programming and Literacy Courses, Qusay H. Mahmoud and Allan Dyer, University of Guelph, Canada, ACMSE, 2007. [Owner08] SunSPOT Owners Manual, Sun Microsystems, Sun Labs, August 2008. [Oesterhout] Why Threads Are A Bad Idea (for most purposes), John Ousterhout, Sun Microsystems Laboratories, 1995. [Papert83] Mindstorms, Children, Computers and Powerful Ideas, Seymor Papert, MIT Press, 1983. [Schwill96] Fundamental Ideas of Computer Science, Andreas Schwill, Fachbereich Mathematik/Informatik - Universität Paderborn, 1996. [Solarium08] Using the SunSPOT Emulator, Ron Goldman, Sun Microsystems, June 2008. [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, 2006. [Sutter05] The Free Lunch is Over - A Fundamental Turn Toward Concurrency in Software, Herb Sutter, Dr. Dobb s Journal, 30(3), March 2005. [Theory08] SunSPOT Theory of Operation, Sun Microsystems, Sun Labs, August 2008. [Tmini07] Tmote Mini Datasheet, Moteiv Corporation, 2007. [Wing06] Computational Thinking, Jeannette M. Wing, Viewpoint in Communications of the ACM, Vol. 49, No. 3, March 2006. 56

Appendix A Experiment descriptions A.1 Experiment 1 57

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: 20 30 minutes Equipment: 3 free ranging SunSPOTs, 1 SunSPOT base station, one laptop with Netbeans and the SunSPOT SDK.

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

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: 20-30 minutes Equipment: 4 free ranging SunSPOTs, 1 SunSPOT base station, one laptop with Netbeans and the SunSPOT SDK.

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

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 http://twitter.com/sunspotdemo 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: 20-30 minutes Equipment: 4-5 free ranging SunSPOTs or emulated SunSPOTs, 1 SunSPOT base station, one laptop with Netbeans and the SunSPOT SDK.

Appendix B Lesson slides B.1 Lesson 1 63

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!

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 802.15.4 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

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 802.15.4 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: https://squawk.dev.java.net/

The Squawk virtual machine A split JVM architecture

But why not embedded Linux? By running on the bare metal, Squawk avoids the need for an operating system (OS) in the SunSPOT, thereby freeing up memory that would otherwise be consumed by an OS. Its makes room for exploratory programming The memory structure - left is Flash right is RAM

Design Overview How to build and deploy programs on the SPOT.java javac.class Squawk suite converter.suite SunSPOT build.bin deploy

Now lets try out a couple of Demos! DEMO The emulator: Solarium

Next: Exercise 1 Setting up the development environment Its time to set up the development environment on your own laptop. You need the following software: 1) Java get it from http://java.sun.com 2) Ant get it from http://ant.apache.org 3) NetBeans get it from http://www.netbeans.org 4) The SunSPOT SDK (blue) get it from http://www.sunspotworld.com Questions???

B.2. LESSON 3 APPENDIX B. LESSON SLIDES B.2 Lesson 3 72

Lesson 3: Introduction to synchronization and semaphores Synchronization and serialization Synchronization In general - making two things happen at the same time In Computer Science its more related to constraints making sure events happen in a certain order like before, during or after: Serialization: Event A must happen before Event B. Mutual exclusion: Events A and B must not happen at the same time.

Clocks, cores and the order of events In computer systems we often need to satisfy synchronization constraints WITHOUT the benefit of a clock. In order to understand software synchronization you need to have a model of how computer programs run. In the simplest model the computer executes one instruction after another in sequence. But what happens when the computer has one or more processors/cores? How can we guarantee the order of events? Message passing Message passing is a real solution for many synchronization problems. Two events are concurrent if we cannot tell by looking at the program which will happen first!

Non-determinism Non-determinism is not knowing by looking at the program what will happen when it executes! Non-determinism is one of the things that make concurrent programming very hard to debug. When two threads run concurrently the order of execution depend on the scheduler. Shared variables Some variables are shared between two or more threads. This is one way to communicate information between threads. Thread A writes a value Thread B reads the value Concurrent writes means there are two or more writers. Concurrent updates means reading a value, computing a new value based on the old and writing the new value for instance an increment operation.

Mutual Exclusion also known as a mutex Mutual exclusion guarantees that only one thread can access a shared variable at a time A critical section is a piece of code that accesses a shared resource. Some synchronization mechanism is required at the entry and exit of the critical section to ensure exclusive use. If we don't enforce the exclusive use a race condition can occur. An operation that cannot be interrupted is said to be atomic Semaphores Originally used on boats later in railroad signals. The Computer Term was invented by the Dutch computer scientist Edsger Dijkstra A semaphore is a protected variable or abstract data type that restrict access to shared resources in a multiprogramming environment.

Semaphores a definition A semaphore is like an integer but with three distinct differences: 1) When you create the semaphore you can initialize it to any integer, but afterwards you can only increment by one or decrement by one. 2) When a thread decrements the semaphore and the result is negative the thread blocks it self and cannot continue until another thread increments the semaphore. This operation is usually called wait(). 3) When a thread increments the semaphore one of the waiting (sleeping) threads gets unblocked and gets activated. This is called waking up the thread. This operation is usually called signal(). Signaling We use the semaphore for signaling. That is one thread signals to another thread to indicate that something has happened. Signaling solves the serialization problem. We create a semaphore named sem and initialize it to 0: sem = new Semaphore(0); // This is called a constructor Thread A Thread B Question: How does this ensure the execution order?

Rendezvous Now lets generalize the problem, so it works both ways. Thread A has to wait for Thread B and vice versa. Thread A Thread B We want to guarantee that a1 happens before b2 and b1 happens before a2 Question: How do we ensure this without too many constraints? Mutex and multiplex A mutex is a binary semaphore that is a semaphore initialized to 1. Question: What happends when we don't enforce a critical section around a shared variable? Run the example program TIVOLI Turnstiles and describe the output. Question: What goes wrong? A multiplex is a semaphore initialized to some value N. This is also known as a counting semaphore.

Next : Experiment 3 Lock that door! Run the example program Describe what the program does by looking at the output. What happens when a fourth person tries to access the bathroom? Questions???

B.3. LESSON 4 APPENDIX B. LESSON SLIDES B.3 Lesson 4 80

Lesson 4: Introduction to deadlocks and starvation What is a deadlock? A deadlock is a situation wherein two or more competing actions are waiting for the other to finish, and thus neither ever does. In computer science a deadlock refers to a specific condition when two or more processes are each waiting for each other to release a shared resource. Deadlocks are particular troubling because there are no general solution to avoid them! Deadlocks are some times called a deadly embrace

What does a deadlock look like? Nothing really... Java applications do not recover from deadlocks, so its worthwhile to ensure that your design precludes the conditions that could cause it! Database systems are designed to detect and recover from deadlocks One of the problems is that deadlocks rarely manifest themselves immediately. Necessary conditions for deadlocks to occur 1) Mutual Exclusion condition 2) Hold and wait condition 3) No pre-emption condition 4) Circular wait condition

Deadlock prevention You can prevent a deadlock by eliminating one of the four conditions: 1) Removing mutual exclusion means that no process/thread have exclusive access to a resource. Algorithms that avoid mutual exclusion are called nonblocking synchronization algorithms. 3) Removing no-preemption means that a process/thread holding a resource and requests another resource that cannot be allocated immediately needs to free all currently held resources. But this is not always a good idea... 2) Removing hold-and-wait means requiring process/threads to request ALL resources before starting up. But this is very inefficient and the advanced knowledge is hard to satisfy. But the state of preempted resources has to be saved and later restored, which is not practical think of a printer... 4) Removing circular wait means disabling interrupts during critical sections and use a hierarchy to determine a partial ordering of resources. Deadlock avoidance You can compare deadlock prevention and deadlock avoidance as a traffic light and a police officer directing traffic. The system dynamically considers every request and decides whether it is safe to grant it at this point, but the system needs more a priori information about potential use of resources. Deadlock avoidance allows more concurrency. There are two available avoidance algorithms: The Resource Allocation Graph Algorithm The Bankers Algorithm

What is starvation? In Computer Science starvation is when a process or thread is perpetually denied necessary resources like CPU cycles. Without those resources, the program can never finish its task! Starvation is similar in effect to deadlocks. Starvation in Java applications can be caused by inappropriate use of thread priorities. It is generally wise to resist the temptation to tweak thread priorities and leave it up to the operating system scheduler instead. What is a livelock? A livelock is a special case of resource starvation. Livelock is a risk with some algorithms that detect and recover from deadlock. If more than one process takes action, the deadlock detection algorithm can repeatedly trigger. You can compare it to two people trying to pass each other in a narrow corridor but both keep stepping aside for the other due to politeness, thus blocking the way.

How to spot and avoid deadlocks? If two threads attempt to acquire the same lock but in a different order, we talk about a lock-ordering deadlock. 1) A program that never acquires more than one lock at a time cannot experience lock-ordering deadlocks 2) Lock ordering must be part of your design 3) If you use fine-grained locking audit your code for deadlock freedom! 4) Use open calls whenever possible calling a method with no locks held is called an open call Next: Experiment 3 The twittering CS Run the example program Describe what the program does by looking at the output What happens when everybody picks up the right half of the keyboard? How can we guarantee that all Computer Scientists will be able to Twitter at some point?

Questions???

Appendix C Source code C.1 Experiment 2 - LockTheDoor-onSPOT Application.java / S i d s e l Jensen <purps@diku. dk> 2 Experiment 1 : Lock t h a t door On SPOT app I l l u s t r a t i o n of a multiplex 4 / 6 package net. java. dev. netbeansspot ; 8 import javax. microedition. io. Connector ; import javax. microedition. io. Datagram ; 10 import javax. microedition. io. DatagramConnection ; import com. sun. spot. i o. j2me. radiogram. RadiogramConnection ; 12 import com. sun. spot. i o. j2me. radiostream. RadiostreamConnection ; import com. sun. spot. p e r i p h e r a l. Spot ; 14 import com. sun. spot. p e r i p h e r a l. TimeoutException ; import com. sun. spot. p e r i p h e r a l. radio. IRadioPolicyManager ; 16 import com. sun. spot. u t i l. U t i l s ; 18 import com. sun. spot. sensorboard. EDemoBoard ; 20 import com. sun. spot. sensorboard. p e r i p h e r a l. ISwitch ; import com. sun. spot. sensorboard. p e r i p h e r a l. ITriColorLED ; 22 import com. sun. spot. sensorboard. p e r i p h e r a l. LEDColor ; import com. sun. spot. u t i l. IEEEAddress ; 24 import java. io. ; import java. io. IOException ; 26 import javax. microedition. midlet. MIDlet ; 28 import javax. microedition. midlet. MIDletStateChangeException ; 30 public c l a s s Application extends MIDlet { 32 p r i v a t e ITriColorLED [ ] leds = EDemoBoard. g e t I n s t a n c e ( ). getleds ( ) ; 34 p r i v a t e ISwitch sw1 ; //Variable to hold the switch. 87

C.1. EXPERIMENT 2 - LOCKTHEDOOR-ONSPOT APPLICATION.JAVA APPENDIX C. SOURCE CODE 36 p r i v a t e S t r i n g message = empty ; 38 // We always wish to send and r e c e i v e from the b a s e s t a t i o n p r i v a t e S t r i n g BSAddr = 0014.4 F01. 0 0 0 0. 1 0 C2 ; 40 p r i v a t e DataInputStream in = n u l l ; p r i v a t e DataOutputStream out = n u l l ; 42 p r i v a t e DatagramConnection dgbs = n u l l ; p r i v a t e RadiostreamConnection conn = n u l l ; 44 p r i v a t e boolean connected = f a l s e ; p r i v a t e boolean talkedtobs = f a l s e ; 46 p r i v a t e S t r i n g port = ; p r i v a t e IEEEAddress myaddr = 48 new IEEEAddress ( Spot. g e t I n s t a n c e ( ). getradiopolicymanager ( ). getieeeaddress ( ) ) ; 50 synchronized public void sendmessage ( S t r i n g m){ 52 t r y { Datagram dgreply = dgbs. newdatagram ( dgbs. getmaximumlength ( ) ) ; 54 dgreply. writeutf (m) ; dgbs. send ( dgreply ) ; 56 catch ( IOException ex ) { ex. p r i n t S t a c k T r a c e ( ) ; 58 60 public void iamalive ( ) { 62 t r y { 64 while ( talkedtobs == f a l s e ) { System. out. p r i n t l n ( Waiting f o r BS to c o n t a c t c l i e n t ) ; 66 i f ( dgbs == n u l l ) dgbs = ( DatagramConnection ) Connector. open ( radiogram :// + BSAddr + : 3 7 ) ; 68 Datagram dg = dgbs. newdatagram ( dgbs. getmaximumlength ( ) ) ; 70 dgbs. r e c e i v e ( dg ) ; // hang here message = dg. readutf ( ) ; 72 i f ( message. equalsignorecase ( Ping? ) ) { sendmessage ( I am a l i v e ) ; 74 System. out. p r i n t l n ( Sent : I am a l i v e to b a s e s t a t i o n ) ; 76 //wait f o r msg with portnumber dgbs. r e c e i v e ( dg ) ; // hang here 78 message = dg. readutf ( ) ; System. out. p r i n t l n ( Received portnumber : + message + from BS ) ; 80 port = message ; 82 talkedtobs = true ; dgbs. c l o s e ( ) ; 84 message = empty ; e l s e { 86 System. out. p r i n t l n ( Wrong i n i t i a l i s a t i o n msg from b a s e s t a t i o n ) ; 88

APPENDIX C.1. SOURCE EXPERIMENT CODE 2 - LOCKTHEDOOR-ONSPOT APPLICATION.JAVA 88 catch ( IOException e ) { 90 System. out. p r i n t l n ( No route to 0014.4 F01. 0 0 0 0. 1 0 C2 ) ; f i n a l l y { 92 94 public void connect ( S t r i n g Addr ) { 96 connected = f a l s e ; 98 t r y { conn = 100 ( RadiostreamConnection ) Connector. open ( radiostream :// + Addr + : + port ) ; in = ( DataInputStream ) conn. opendatainputstream ( ) ; 102 out = ( DataOutputStream ) conn. opendataoutputstream ( ) ; catch ( IOException ex ) { 104 ex. p r i n t S t a c k T r a c e ( ) ; 106 connected = true ; 108 110 public void turnoffleds ( ) { f o r ( i n t i = 0 ; i < 8 ; i ++) { 112 leds [ i ]. s e t O f f ( ) ; // turn o f f a l l LEDs 114 116 public void turnonleds ( ) { f o r ( i n t j = 0 ; j < 8 ; j ++) { // turn on a l l LEDs 118 leds [ j ]. setcolor ( LEDColor.RED ) ; leds [ j ]. seton ( ) ; 120 122 public void flashblue ( ) { 124 f o r ( i n t k = 0 ; k < 8 ; k++) { // turn on a l l LEDs leds [ k ]. setcolor ( LEDColor. BLUE ) ; 126 leds [ k ]. seton ( ) ; U t i l s. sleep ( 2 0 0 ) ; // on f o r 1/5 second 128 leds [ k ]. s e t O f f ( ) ; 130 132 synchronized public void startreceiverthread ( ) { new Thread ( ) { 134 public void run ( ) { // S t r i n g tmp = n u l l ; 136 conn. settimeout ( 1 0 0 0 ) ; 138 t r y { i f (! connected ) { 140 connect ( BSAddr ) ; 89

C.1. EXPERIMENT 2 - LOCKTHEDOOR-ONSPOT APPLICATION.JAVA APPENDIX C. SOURCE CODE 142 t r y { 144 message = in. readutf ( ) ; System. out. p r i n t l n ( Received : + message + from GW ) ; 146 catch ( TimeoutException e ) { System. out. p r i n t l n ( Timeout... other end i s not responding ) ; 148 150 catch ( IOException e ) { System. out. p r i n t l n ( Could not open r e c e i v e r connection ) ; 152 e. p r i n t S t a c k T r a c e ( ) ; return ; 154 156. s t a r t ( ) ; 158 synchronized public S t r i n g r e c e i v e ( ) { 160 S t r i n g tmp = ; //conn. settimeout ( 1 0 0 0 ) ; 162 t r y { 164 i f (! connected ) { connect ( BSAddr ) ; 166 168 t r y { while ( tmp. equalsignorecase ( ) ) { 170 tmp = in. readutf ( ) ; 172 System. out. p r i n t l n ( Received : + tmp + from GW ) ; catch ( TimeoutException e ) { 174 System. out. p r i n t l n ( Timeout... other end i s not responding ) ; 176 catch ( IOException e ) { 178 System. out. p r i n t l n ( Could not open r e c e i v e r connection ) ; e. p r i n t S t a c k T r a c e ( ) ; 180 return tmp ; 182 i f ( tmp == n u l l ) { tmp = ; 184 return tmp ; 186 188 synchronized public void startsenderthread ( f i n a l S t r i n g msg) { new Thread ( ) { 190 public void run ( ) { 192 t r y { i f (! connected ) { 90

APPENDIX C.1. SOURCE EXPERIMENT CODE 2 - LOCKTHEDOOR-ONSPOT APPLICATION.JAVA 194 connect ( BSAddr ) ; 196 out. writeutf (msg ) ; 198 System. out. p r i n t l n ( Sending : + msg ) ; out. f l u s h ( ) ; 200 catch ( IOException ex ) { System. out. p r i n t l n ( Could not open stream output connection ) ; 202 ex. p r i n t S t a c k T r a c e ( ) ; return ; 204 206. s t a r t ( ) ; 208 p r i v a t e void initandrun ( ) throws IOException { 210 sw1 = EDemoBoard. g e t I n s t a n c e ( ). getswitches ( ) [ 0 ] ; 212 System. out. p r i n t l n ( Hi, my address i s : + myaddr. asdottedhex ( ) ) ; 214 iamalive ( ) ; 216 startsw1watchthread ( ) ; 218 public void sw1closed ( ) { 220 S t r i n g t o i l e t m s g = ; 222 System. out. p r i n t l n ( Switch 1 closed. ) ; 224 i f ( leds [ 0 ]. ison ( ) == true ) { 226 // When pressing the SW1 button we wish to leave the t o i l e t t o i l e t m s g = one t o i l e t a v a i l a b l e, sent from : + myaddr. asdottedhex ( ) ; 228 startsenderthread ( t o i l e t m s g ) ; 230 System. out. p r i n t l n ( There i s now : 1 t o i l e t a v a i l a b l e ) ; turnoffleds ( ) ; 232 e l s e { // I f the t o i l e t isn t locked we wish to enter 234 t o i l e t m s g = wish to lock 1 t o i l e t, sent from : + myaddr. asdottedhex ( ) ; startsenderthread ( t o i l e t m s g ) ; 236 System. out. p r i n t l n ( Wish to acquire 1 t o i l e t awaiting answer ) ; 238 //while ( true ) { // Receive the answer? 240 //startreceiverthread ( ) ; message = r e c e i v e ( ) ; 242 // Sleep a l i t t l e wait f o r host app to respond // U t i l s. sleep ( 4 0 0 ) ; 244 i f ( message. equalsignorecase ( OK ) ) { // We got an OK we can now lock the t o i l e t 246 System. out. p r i n t l n ( This t o i l e t i s now occupied! ) ; 91

C.1. EXPERIMENT 2 - LOCKTHEDOOR-ONSPOT APPLICATION.JAVA APPENDIX C. SOURCE CODE turnonleds ( ) ; 248 message = ; e l s e i f ( message. equalsignorecase ( NO ) ) { 250 // Bummer a l l t o i l e t s are taken System. out. p r i n t l n ( No t o i l e t s c u r r e n t l y a v a i l a b l e ) ; 252 flashblue ( ) ; turnoffleds ( ) ; 254 message = ; e l s e { 256 System. out. p r i n t l n ( No answer from host ) ; 258 // 260 262 public void sw1opened ( ) { System. out. p r i n t l n ( Switch 1 opened. ) ; 264 266 public void startsw1watchthread ( ) { 268 new Thread ( ) { public void run ( ) { 270 while ( true ){ sw1. waitforchange ( ) ; 272 i f ( sw1. isclosed ( ) ) { sw1closed ( ) ; 274 e l s e { sw1opened ( ) ; 276 278. s t a r t ( ) ; 280 282 p r o t e c t e d void startapp ( ) throws MIDletStateChangeException { 284 t r y { initandrun ( ) ; 286 catch ( IOException ex ) { //A problem in reading the sensors. ex. p r i n t S t a c k T r a c e ( ) ; 288 290 protected void pauseapp ( ) { 292 // This i s not c u r r e n t l y c a l l e d by the Squawk VM 294 / 296 Called i f the MIDlet i s terminated by the system. I. e. i f startapp throws any exception other than MIDletStateChangeException, 298 i f the i s o l a t e running the MIDlet i s k i l l e d with I s o l a t e. e x i t ( ), or i f VM. stopvm ( ) i s c a l l e d. 92

APPENDIX C. SOURCE CODE C.2. EXPERIMENT 2 - LOCKTHEDOOR-ONHOST SUNSPOTHOSTAPPLICATION.JAVA 300 I t i s not c a l l e d i f MIDlet. notifydestroyed ( ) was c a l l e d. 302 @param unconditional I f true when t h i s method i s called, the MIDlet must 304 cleanup and r e l e a s e a l l resources. I f f a l s e the MIDlet may throw MIDletStateChangeException to i n d i c a t e i t does not want to be destroyed 306 a t t h i s time. / 308 protected void destroyapp ( boolean unconditional ) throws MIDletStateChangeException { // TODO 310 C.2 Experiment 2 - LockTheDoor-onHost SunSpotHostApplication.java 1 / S i d s e l Jensen <purps@diku. dk> Experiment 1 : Lock t h a t door On Host app 3 I l l u s t r a t i o n of a multiplex / 5 package net. java. dev. netbeansspot ; 7 import com. sun. spot. p e r i p h e r a l. NoRouteException ; 9 import java. u t i l. logging. Level ; import java. u t i l. logging. Logger ; 11 import javax. microedition. io. Connector ; import javax. microedition. io. Datagram ; 13 import javax. microedition. io. DatagramConnection ; import com. sun. spot. i o. j2me. radiogram. RadiogramConnection ; 15 import com. sun. spot. i o. j2me. radiostream. RadiostreamConnection ; 17 //import com. sun. spot. p e r i p h e r a l. NoRouteException ; import com. sun. spot. u t i l. U t i l s ; 19 import java. io. ; import java. io. IOException ; 21 import java. u t i l. ArrayList ; import java. u t i l. L i s t ; 23 public c l a s s SunSpotHostApplication { 25 p r i v a t e s t a t i c long MAX AVAILABLE = 3 ; 27 p r i v a t e Semaphore t o i l e t s = new Semaphore (MAX AVAILABLE ) ; 29 p r i v a t e S t r i n g message = empty ; 31 p r i v a t e L i s t c l i e n t s = new ArrayList ( ) ; p r i v a t e DatagramConnection dgbconn, dgclient = n u l l ; 33 p r i v a t e boolean connected1, connected2, connected3, connected4 = f a l s e ; p r i v a t e SpotRadio s p o t c l i e n t 1 = new SpotRadio ( ) ; 93

C.2. EXPERIMENT 2 - LOCKTHEDOOR-ONHOST SUNSPOTHOSTAPPLICATION.JAVA APPENDIX C. SOURCE CODE 35 p r i v a t e SpotRadio s p o t c l i e n t 2 = new SpotRadio ( ) ; p r i v a t e SpotRadio s p o t c l i e n t 3 = new SpotRadio ( ) ; 37 p r i v a t e SpotRadio s p o t c l i e n t 4 = new SpotRadio ( ) ; p r i v a t e i n t port = 1 0 0 ; 39 synchronized public void sendmessage ( S t r i n g m, S t r i n g IEEEaddress ){ 41 t r y { 43 dgclient = ( DatagramConnection ) Connector. open ( radiogram :// + IEEEaddress + : 3 7 ) ; 45 catch ( IOException ex ) { System. out. p r i n t l n ( Could not open radiogram connection to c l i e n t ) ; 47 ex. p r i n t S t a c k T r a c e ( ) ; return ; 49 51 t r y { Datagram c l i e n t r e p l y = dgclient. newdatagram ( dgclient. getmaximumlength ( ) ) ; 53 c l i e n t r e p l y. writeutf (m) ; dgclient. send ( c l i e n t r e p l y ) ; 55 dgclient. c l o s e ( ) ; catch ( IOException ex ) { 57 ex. p r i n t S t a c k T r a c e ( ) ; 59 61 synchronized public void sendbroadcastmessage ( S t r i n g m){ t r y { 63 i f ( dgbconn == n u l l ) dgbconn = ( DatagramConnection ) Connector. open ( radiogram :// broadcast : 3 7 ) ; 65 catch ( IOException ex ) { System. out. p r i n t l n ( Could not open radiogram broadcast connection ) ; 67 ex. p r i n t S t a c k T r a c e ( ) ; return ; 69 t r y { 71 Datagram dg = dgbconn. newdatagram ( dgbconn. getmaximumlength ( ) ) ; dg. writeutf (m) ; 73 dgbconn. send ( dg ) ; catch ( IOException ex ) { 75 ex. p r i n t S t a c k T r a c e ( ) ; 77 79 public void a l i v e s p o t s ( ) { S t r i n g caddress = n u l l ; 81 t r y { 83 RadiogramConnection conn = ( RadiogramConnection ) Connector. open ( radiogram : / / : 3 7 ) ; 85 Datagram dgreply = conn. newdatagram ( conn. getmaximumlength ( ) ) ; 87 System. out. p r i n t l n ( Sending broadcast ping to c l i e n t s ) ; 94

APPENDIX C. SOURCE CODE C.2. EXPERIMENT 2 - LOCKTHEDOOR-ONHOST SUNSPOTHOSTAPPLICATION.JAVA sendbroadcastmessage ( Ping? ) ; 89 // loop f o r as long as timeout value i s valid f o r... 91 while ( true ) { conn. settimeout ( 5 0 0 ) ; 93 conn. r e c e i v e ( dgreply ) ; S t r i n g question = dgreply. readutf ( ) ; 95 S t r i n g portnumber = ; 97 i f ( question. equals ( I am a l i v e ) ) { // f e t c h address from c l i e n t spot 99 caddress = dgreply. getaddress ( ) ; // check i f we already have t h a t c l i e n t in the l i s t 101 i f ( c l i e n t s. contains ( caddress )!= true ) { // i f not put c l i e n t address in c l i e n t l i s t 103 c l i e n t s. add ( caddress ) ; System. out. p r i n t l n ( Added new c l i e n t to l i s t : + caddress ) ; 105 port = 100 + c l i e n t s. indexof ( caddress ) ; portnumber = I n t e g e r. t o S t r i n g ( port ) ; 107 sendmessage ( portnumber, caddress ) ; System. out. p r i n t l n ( Sent portnumber + portnumber + 109 to c l i e n t : + caddress ) ; e l s e { 111 System. out. p r i n t l n ( C l i e n t already added to l i s t! ) ; 113 e l s e { System. out. p r i n t l n ( I n c o r r e c t reply from c l i e n t ) ; 115 dgreply. r e s e t ( ) ; 117 catch ( IOException e ) { 119 System. out. p r i n t l n ( C l i e n t closed connection ) ; f i n a l l y { 121 //conn. c l o s e ( ) ; 123 125 public S t r i n g firstword ( S t r i n g s ) { S t r i n g firstword = ; 127 i n t spaceindex = s. indexof ( ) ; 129 i f ( spaceindex == 1) { firstword = s ; 131 e l s e { firstword = s. substring ( 0, spaceindex ) ; 133 //System. out. p r i n t l n ( F i r s t word in message i s : + firstword ) ; 135 return firstword ; 137 public S t r i n g lastword ( S t r i n g s ) { 139 S t r i n g lastword = ; 95

C.2. EXPERIMENT 2 - LOCKTHEDOOR-ONHOST SUNSPOTHOSTAPPLICATION.JAVA APPENDIX C. SOURCE CODE 141 i n t spaceindex = s. indexof ( ) ; i f ( spaceindex == 1) { 143 lastword = s ; e l s e { 145 lastword = s. substring ( s. lastindexof ( ) + 1 ) ; 147 return lastword ; 149 151 synchronized public void startreceiverthread ( f i n a l S t r i n g address, f i n a l i n t c l i e n t ) { 153 new Thread ( ) { public void run ( ) { 155 i f ( c l i e n t == 0) { 157 i f (! connected1 ) { s p o t c l i e n t 1. connect ( address, c l i e n t ) ; 159 connected1 = true ; 161 message = s p o t c l i e n t 1. r e c e i v e ( ) ; 163 e l s e i f ( c l i e n t == 1) { i f (! connected2 ) { 165 s p o t c l i e n t 2. connect ( address, c l i e n t ) ; connected2 = true ; 167 message = s p o t c l i e n t 2. r e c e i v e ( ) ; 169 e l s e i f ( c l i e n t == 2) { 171 i f (! connected3 ) { s p o t c l i e n t 3. connect ( address, c l i e n t ) ; 173 connected3 = true ; 175 message = s p o t c l i e n t 3. r e c e i v e ( ) ; 177 e l s e i f ( c l i e n t == 3) { i f (! connected4 ) { 179 s p o t c l i e n t 4. connect ( address, c l i e n t ) ; connected4 = true ; 181 message = s p o t c l i e n t 4. r e c e i v e ( ) ; 183 e l s e { 185 System. out. p r i n t l n ( C l i e n t l i s t not long enough! ) ; 187 189. s t a r t ( ) ; 191 synchronized public void 193 startsenderthread ( f i n a l S t r i n g msg, f i n a l S t r i n g address, f i n a l i n t c l i e n t ) { 96

APPENDIX C. SOURCE CODE C.2. EXPERIMENT 2 - LOCKTHEDOOR-ONHOST SUNSPOTHOSTAPPLICATION.JAVA new Thread ( ) { 195 public void run ( ) { 197 t r y { i f ( c l i e n t == 0) { 199 i f (! connected1 ) { s p o t c l i e n t 1. connect ( address, c l i e n t ) ; 201 connected1 = true ; 203 s p o t c l i e n t 1. send (msg ) ; 205 e l s e i f ( c l i e n t == 1) { i f (! connected2 ) { 207 s p o t c l i e n t 2. connect ( address, c l i e n t ) ; connected2 = true ; 209 s p o t c l i e n t 2. send (msg ) ; 211 e l s e i f ( c l i e n t == 2) { 213 i f (! connected3 ) { s p o t c l i e n t 3. connect ( address, c l i e n t ) ; 215 connected3 = true ; 217 s p o t c l i e n t 3. send (msg ) ; 219 e l s e i f ( c l i e n t == 3) { i f (! connected4 ) { 221 s p o t c l i e n t 4. connect ( address, c l i e n t ) ; connected4 = true ; 223 s p o t c l i e n t 4. send (msg ) ; 225 e l s e { 227 System. out. p r i n t l n ( C l i e n t l i s t not long enough! ) ; 229 catch ( IOException ex ) { 231 Logger. getlogger ( SunSpotHostApplication. c l a s s. getname ( ) ). log ( Level. SEVERE, null, ex ) ; 233 235. s t a r t ( ) ; 237 public void initandrun ( ) { 239 S t r i n g incomingmsg = ; S t r i n g spot = ; 241 i n t i = 0 ; 243 // E s t a b l i s h how many c l i e n t s we are t a l k i n g to... a l i v e s p o t s ( ) ; 245 while ( true ) { 97

C.2. EXPERIMENT 2 - LOCKTHEDOOR-ONHOST SUNSPOTHOSTAPPLICATION.JAVA APPENDIX C. SOURCE CODE 247 // check our c l i e n t s in a round robin fashion // f o r each c l i e n t in our l i s t do... 249 f o r ( i = 0 ; i < c l i e n t s. s i z e ( ) ; i ++ ) { 251 //System. out. p r i n t l n ( Current c l i e n t address : + c l i e n t s. get ( i ) ) ; //System. out. p r i n t l n ( P r i n t i : + I n t e g e r. t o S t r i n g ( i ) ) ; 253 startreceiverthread ( ( S t r i n g ) c l i e n t s. get ( i ), i ) ; // U t i l s. sleep ( 2 0 0 ) ; 255 // do we r e c e i v e a wish to lock a t o i l e t? // i s i t a wish to acquire msg? 257 // i f (! message. equalsignorecase ( ) ) { // System. out. p r i n t l n ( Received message : + message ) ; 259 // incomingmsg = firstword ( message ) ; 261 spot = lastword ( message ) ; 263 i f ( incomingmsg. equalsignorecase ( wish ) ) { 265 // i f yes then send OK i f t o i l e t. permits > 0 and c a l l t o i l e t. acquire i f ( t o i l e t s. permits ( ) > 0) { 267 t r y { 269 t o i l e t s. acquire ( ) ; catch ( InterruptedException ex ) { 271 Logger. getlogger ( SunSpotHostApplication. c l a s s. getname ( ) ). log ( Level. SEVERE, null, ex ) ; 273 startsenderthread ( OK, spot, c l i e n t s. indexof ( spot ) ) ; 275 System. out. p r i n t l n ( t o i l e t occupied 277 + t o i l e t s. permits ( ) + s t i l l a v a i l a b l e ) ; e l s e { 279 // e l s e send NO startsenderthread ( NO, spot, c l i e n t s. indexof ( spot ) ) ; 281 System. out. p r i n t l n ( No f r e e t o i l e t s at the time being! ) ; 283 e l s e i f ( incomingmsg. equalsignorecase ( one ) ) { 285 // do we r e c e i v e a wish to unlock a t o i l e t? // i f yes then c a l l t o i l e t. r e l e a s e ( ) 287 t o i l e t s. r e l e a s e ( ) ; 289 System. out. p r i n t l n ( t o i l e t r e l e a s e d + t o i l e t s. permits ( ) + s t i l l a v a i l a b l e ) ; 291 e l s e { //System. out. p r i n t l n ( I d l e ) ; 293 incomingmsg = ; 295 message = ; U t i l s. sleep ( 2 0 0 ) ; 297 i = 0 ; 299 98

APPENDIX C. C.3. SOURCE EXPERIMENT CODE 2 - LOCKTHEDOOR-ONHOST SPOTRADIO.JAVA 301 public s t a t i c void main ( S t r i n g [ ] args ) { 303 SunSpotHostApplication App = new SunSpotHostApplication ( ) ; App. initandrun ( ) ; 305 C.3 Experiment 2 - LockTheDoor-onHost SpotRadio.java / 2 To change t h i s template, choose Tools Templates and open the template in the e d i t o r. 4 / 6 package net. java. dev. netbeansspot ; 8 import com. sun. spot. i o. j2me. radiostream. RadiostreamConnection ; import com. sun. spot. p e r i p h e r a l. NoRouteException ; 10 import java. io. DataInputStream ; import java. io. DataOutputStream ; 12 import java. io. IOException ; import java. u t i l. logging. Level ; 14 import java. u t i l. logging. Logger ; import javax. microedition. io. Connector ; 16 / 18 @author purple 20 / public c l a s s SpotRadio { 22 p r i v a t e DataInputStream in = n u l l ; 24 p r i v a t e DataOutputStream out = n u l l ; p r i v a t e boolean connected = f a l s e ; 26 p r i v a t e RadiostreamConnection conn = n u l l ; p r i v a t e S t r i n g IEEE = n u l l ; 28 p r i v a t e i n t port = 0 ; 30 SpotRadio ( ) { 32 connected = f a l s e ; 34 public void connect ( S t r i n g address, i n t portnumber ) { 36 IEEE = address ; port = 100 + portnumber ; 38 t r y { 40 i f ( conn == n u l l ) { conn = ( RadiostreamConnection ) Connector. open ( radiostream :// + address + : + port ) ; 99

C.4. EXPERIMENT 3 - TWITTERINGCS-ONSPOT APPLICATION.JAVA APPENDIX C. SOURCE CODE 42 in = ( DataInputStream ) conn. opendatainputstream ( ) ; 44 out = ( DataOutputStream ) conn. opendataoutputstream ( ) ; catch ( IOException ex ) { 46 Logger. getlogger ( SpotRadio. c l a s s. getname ( ) ). log ( Level. SEVERE, null, ex ) ; 48 connected = true ; 50 52 public void send ( S t r i n g msg) throws IOException, NoRouteException { out. writeutf (msg ) ; 54 out. f l u s h ( ) ; System. out. p r i n t l n ( Message sent : + msg + to + IEEE ) ; 56 58 public S t r i n g r e c e i v e ( ) { S t r i n g reply = ; 60 t r y { 62 reply = in. readutf ( ) ; System. out. p r i n t l n ( Received : + reply ) ; 64 catch ( IOException e ) { e. p r i n t S t a c k T r a c e ( ) ; 66 68 i f ( reply == n u l l ) { reply = ; 70 return reply ; 72 74 public void closeconnection ( ) { i f ( connected == f a l s e ) 76 return ; connected = f a l s e ; 78 t r y { in. c l o s e ( ) ; 80 out. c l o s e ( ) ; conn. c l o s e ( ) ; 82 catch ( IOException e ) { e. p r i n t S t a c k T r a c e ( ) ; 84 86 C.4 Experiment 3 - TwitteringCS-OnSPOT Application.java 1 / S i d s e l Jensen <purps@diku. dk> Experiment 3 : The t w i t t e r i n g Computer S c i e n t i s t s On SPOT app 100

APPENDIX C. C.4. SOURCE EXPERIMENT CODE 3 - TWITTERINGCS-ONSPOT APPLICATION.JAVA 3 I l l u s t r a t i o n of deadlocks and s t a r v a t i o n / 5 package net. java. dev. netbeansspot ; 7 import javax. microedition. io. Connector ; 9 import javax. microedition. io. Datagram ; import javax. microedition. io. DatagramConnection ; 11 import com. sun. spot. i o. j2me. radiogram. RadiogramConnection ; import com. sun. spot. i o. j2me. radiostream. RadiostreamConnection ; 13 import com. sun. spot. p e r i p h e r a l. Spot ; import com. sun. spot. p e r i p h e r a l. TimeoutException ; 15 import com. sun. spot. p e r i p h e r a l. radio. IRadioPolicyManager ; 17 import com. sun. spot. u t i l. U t i l s ; 19 import com. sun. spot. sensorboard. EDemoBoard ; import com. sun. spot. sensorboard. p e r i p h e r a l. ISwitch ; 21 import com. sun. spot. sensorboard. p e r i p h e r a l. ITriColorLED ; import com. sun. spot. sensorboard. p e r i p h e r a l. LEDColor ; 23 import com. sun. spot. u t i l. IEEEAddress ; import java. io. ; 25 import java. io. IOException ; import java. u t i l. Random ; 27 import javax. microedition. midlet. MIDlet ; 29 import javax. microedition. midlet. MIDletStateChangeException ; 31 public c l a s s Application extends MIDlet { 33 p r i v a t e ITriColorLED [ ] leds = EDemoBoard. g e t I n s t a n c e ( ). getleds ( ) ; 35 p r i v a t e ISwitch sw1, sw2 ; //Variable to hold the switch. 37 p r i v a t e S t r i n g message = empty ; 39 // We always wish to send and r e c e i v e from the b a s e s t a t i o n p r i v a t e S t r i n g BSAddr = 0014.4 F01. 0 0 0 0. 1 0 C2 ; 41 p r i v a t e DataInputStream in = n u l l ; p r i v a t e DataOutputStream out = n u l l ; 43 p r i v a t e DatagramConnection dgbs = n u l l ; p r i v a t e RadiostreamConnection conn = n u l l ; 45 p r i v a t e boolean connected = f a l s e ; p r i v a t e boolean talkedtobs = f a l s e ; 47 p r i v a t e boolean LEFT, RIGHT = f a l s e ; p r i v a t e S t r i n g port = ; 49 p r i v a t e IEEEAddress myaddr = new IEEEAddress ( Spot. g e t I n s t a n c e ( ). getradiopolicymanager ( ). getieeeaddress ( ) ) ; 51 Random rand = new Random( System. currenttimemillis ( ) ) ; 53 S t r i n g [ ] sayings = { I can f i n a l l y express my thoughts, 55 D j i k s t r a who?, 101

C.4. EXPERIMENT 3 - TWITTERINGCS-ONSPOT APPLICATION.JAVA APPENDIX C. SOURCE CODE What took you so long?, 57 Duke you rock my world!, I don t eat s p a g h e t t i I p r e f e r pizza, 59 Gimme back my keyboard, I m s t a r v i n g here!, 61 I dont know any deadlocks... ; 63 synchronized public void sendmessage ( S t r i n g m){ 65 t r y { 67 Datagram dgreply = dgbs. newdatagram ( dgbs. getmaximumlength ( ) ) ; dgreply. writeutf (m) ; 69 dgbs. send ( dgreply ) ; catch ( IOException ex ) { 71 ex. p r i n t S t a c k T r a c e ( ) ; 73 75 public void iamalive ( ) { 77 t r y { while ( talkedtobs == f a l s e ) { 79 System. out. p r i n t l n ( Waiting f o r BS to c o n t a c t c l i e n t ) ; i f ( dgbs == n u l l ) dgbs = 81 ( DatagramConnection ) Connector. open ( radiogram :// + BSAddr + : 3 7 ) ; Datagram dg = dgbs. newdatagram ( dgbs. getmaximumlength ( ) ) ; 83 dgbs. r e c e i v e ( dg ) ; // hang here 85 message = dg. readutf ( ) ; i f ( message. equalsignorecase ( Ping? ) ) { 87 sendmessage ( I am a l i v e ) ; System. out. p r i n t l n ( Sent : I am a l i v e to b a s e s t a t i o n ) ; 89 //wait f o r msg with portnumber 91 dgbs. r e c e i v e ( dg ) ; // hang here message = dg. readutf ( ) ; 93 System. out. p r i n t l n ( Received portnumber : + message + from BS ) ; port = message ; 95 talkedtobs = true ; 97 dgbs. c l o s e ( ) ; message = empty ; 99 e l s e { System. out. p r i n t l n ( Wrong i n i t i a l i s a t i o n msg from b a s e s t a t i o n ) ; 101 103 catch ( IOException e ) { System. out. p r i n t l n ( No route to 0014.4 F01. 0 0 0 0. 1 0 C2 ) ; 105 f i n a l l y { 107 102

APPENDIX C. C.4. SOURCE EXPERIMENT CODE 3 - TWITTERINGCS-ONSPOT APPLICATION.JAVA 109 public void connect ( S t r i n g Addr ) { connected = f a l s e ; 111 t r y { 113 conn = ( RadiostreamConnection ) Connector. open ( radiostream :// + Addr + : + port ) ; 115 in = ( DataInputStream ) conn. opendatainputstream ( ) ; out = ( DataOutputStream ) conn. opendataoutputstream ( ) ; 117 catch ( IOException ex ) { ex. p r i n t S t a c k T r a c e ( ) ; 119 121 connected = true ; 123 public void turnoffled ( i n t number ) { 125 leds [ number ]. s e t O f f ( ) ; // turn o f f s p e c i f i c led 127 public void turnonled ( i n t number ) { 129 leds [ number ]. setcolor ( LEDColor.YELLOW) ; leds [ number ]. seton ( ) ; // turn on s p e c i f i c led 131 133 public void flashblue ( ) { f o r ( i n t k = 0 ; k < 8 ; k++) { // turn on a l l LEDs 135 leds [ k ]. setcolor ( LEDColor. BLUE ) ; leds [ k ]. seton ( ) ; 137 U t i l s. sleep ( 2 0 0 ) ; // on f o r 1/5 second leds [ k ]. s e t O f f ( ) ; 139 141 synchronized public void startreceiverthread ( ) { 143 new Thread ( ) { public void run ( ) { 145 S t r i n g rmessage = ; //conn. settimeout ( 1 0 0 0 ) ; 147 while ( true ) { 149 t r y { i f (! connected ) { 151 connect ( BSAddr ) ; 153 t r y { 155 rmessage = in. readutf ( ) ; System. out. p r i n t l n ( Received : + rmessage + from GW ) ; 157 catch ( TimeoutException e ) { System. out. p r i n t l n ( Timeout... other end i s not responding ) ; 159 161 catch ( IOException e ) { 103

C.4. EXPERIMENT 3 - TWITTERINGCS-ONSPOT APPLICATION.JAVA APPENDIX C. SOURCE CODE System. out. p r i n t l n ( Could not open r e c e i v e r connection ) ; 163 e. p r i n t S t a c k T r a c e ( ) ; return ; 165 167 i f ( rmessage. equalsignorecase ( turn r i g h t o f f ) ) { turnoffled ( 7 ) ; 169 RIGHT = f a l s e ; System. out. p r i n t l n ( Right neighbor took keyboard ) ; 171 e l s e i f ( rmessage. equalsignorecase ( turn r i g h t on ) ) { turnonled ( 7 ) ; 173 RIGHT = f a l s e ; System. out. p r i n t l n ( Right neighbor put keyboard down ) ; 175 e l s e i f ( rmessage. equalsignorecase ( turn l e f t o f f ) ) { turnoffled ( 0 ) ; 177 LEFT = f a l s e ; System. out. p r i n t l n ( L e f t neighbor took keyboard ) ; 179 e l s e i f ( rmessage. equalsignorecase ( turn l e f t on ) ) { turnonled ( 0 ) ; 181 LEFT = f a l s e ; System. out. p r i n t l n ( L e f t neighbor put keyboard down ) ; 183 e l s e { //System. out. p r i n t l n ( I n v a l i d message from GW: + message ) ; 185 rmessage = ; 187 189. s t a r t ( ) ; 191 synchronized public S t r i n g r e c e i v e ( ) { 193 S t r i n g tmp = ; //conn. settimeout ( 1 0 0 0 ) ; 195 t r y { 197 i f (! connected ) { connect ( BSAddr ) ; 199 201 t r y { while ( tmp. equalsignorecase ( ) ) { 203 tmp = in. readutf ( ) ; 205 System. out. p r i n t l n ( Received : + tmp + from GW ) ; catch ( TimeoutException e ) { 207 System. out. p r i n t l n ( Timeout... other end i s not responding ) ; 209 catch ( IOException e ) { 211 System. out. p r i n t l n ( Could not open r e c e i v e r connection ) ; e. p r i n t S t a c k T r a c e ( ) ; 213 return tmp ; 104

APPENDIX C. C.4. SOURCE EXPERIMENT CODE 3 - TWITTERINGCS-ONSPOT APPLICATION.JAVA 215 i f ( tmp == n u l l ) { tmp = ; 217 return tmp ; 219 221 synchronized public void startsenderthread ( f i n a l S t r i n g msg) { new Thread ( ) { 223 public void run ( ) { 225 t r y { i f (! connected ) { 227 connect ( BSAddr ) ; 229 out. writeutf (msg ) ; 231 System. out. p r i n t l n ( Sending : + msg ) ; out. f l u s h ( ) ; 233 catch ( IOException ex ) { System. out. p r i n t l n ( Could not open stream output connection ) ; 235 ex. p r i n t S t a c k T r a c e ( ) ; return ; 237 239. s t a r t ( ) ; 241 p r i v a t e void initandrun ( ) throws IOException { 243 sw1 = EDemoBoard. g e t I n s t a n c e ( ). getswitches ( ) [ 0 ] ; 245 sw2 = EDemoBoard. g e t I n s t a n c e ( ). getswitches ( ) [ 1 ] ; 247 System. out. p r i n t l n ( Hi, my address i s : + myaddr. asdottedhex ( ) ) ; 249 iamalive ( ) ; turnonled ( 0 ) ; 251 turnonled ( 7 ) ; startsw1watchthread ( ) ; 253 startsw2watchthread ( ) ; startreceiverthread ( ) ; 255 257 public void sw1closed ( ) { S t r i n g tweetmsg = ; 259 S t r i n g statusmsg = ; 261 System. out. p r i n t l n ( Switch 1 closed. ) ; 263 i f ( leds [ 0 ]. ison ( ) ) { turnoffled ( 0 ) ; 265 System. out. p r i n t l n ( Grabbed l e f t h a l f of keyboard! ) ; LEFT = true ; 267 105

C.4. EXPERIMENT 3 - TWITTERINGCS-ONSPOT APPLICATION.JAVA APPENDIX C. SOURCE CODE // Send message to HOST app about keyboard p a r t taken 269 statusmsg = LEFT taken + myaddr. asdottedhex ( ) ; startsenderthread ( statusmsg ) ; 271 // Check i f we have the other h a l f! 273 i f (RIGHT == true ) { // we got both h a l f s of keyboard and can now t w i t t e r! 275 System. out. p r i n t l n ( Twitter time! ) ; 277 // Send message to host app with t w i t t e r msg tweetmsg = TWEET: + sayings [ rand. n e x t I n t ( sayings. length ) ] + 279 + myaddr. asdottedhex ( ) ; startsenderthread ( tweetmsg ) ; 281 LEFT = f a l s e ; 283 turnonled ( 0 ) ; RIGHT = f a l s e ; 285 turnonled ( 7 ) ; // Send message to HOST app about keyboard a v a i l a b l e 287 289 // Send message to HOST app about keyboard taken e l s e { 291 // e i t h e r someone e l s e took the keyboard h a l f before us or // we are holding i t o u r s e l f 293 i f ( LEFT == true && RIGHT == f a l s e ) { turnonled ( 0 ) ; 295 System. out. p r i n t l n ( Decided to put down l e f t h a l f of keyboard! ) ; LEFT = f a l s e ; 297 // Send message to HOST app about keyboard a v a i l a b l e 299 statusmsg = LEFT f r e e + myaddr. asdottedhex ( ) ; startsenderthread ( statusmsg ) ; 301 e l s e { 303 System. out. p r i n t l n ( L e f t neighbor CS must c u r r e n t l y hold keyboard h a l f! ) ; 305 307 public void sw2closed ( ) { 309 S t r i n g tweetmsg = ; S t r i n g statusmsg = ; 311 System. out. p r i n t l n ( Switch 2 closed. ) ; 313 i f ( leds [ 7 ]. ison ( ) ) { 315 turnoffled ( 7 ) ; System. out. p r i n t l n ( Grabbed r i g h t h a l f of keyboard! ) ; 317 RIGHT = true ; 319 // Send message to HOST app about keyboard p a r t taken statusmsg = RIGHT taken + myaddr. asdottedhex ( ) ; 106

APPENDIX C. C.4. SOURCE EXPERIMENT CODE 3 - TWITTERINGCS-ONSPOT APPLICATION.JAVA 321 startsenderthread ( statusmsg ) ; 323 // Check i f we have the other h a l f! i f ( LEFT == true ) { 325 // we got both h a l f s of keyboard and can now t w i t t e r! System. out. p r i n t l n ( Twitter time! ) ; 327 // Send message to host app with t w i t t e r msg 329 tweetmsg = TWEET: + sayings [ rand. n e x t I n t ( sayings. length ) ] + + myaddr. asdottedhex ( ) ; 331 startsenderthread ( tweetmsg ) ; 333 RIGHT = f a l s e ; turnonled ( 7 ) ; 335 LEFT = f a l s e ; turnonled ( 0 ) ; 337 // Send message to HOST app about keyboard a v a i l a b l e 339 // Send message to HOST app about keyboard taken 341 e l s e { // e i t h e r someone e l s e took the keyboard h a l f before us or 343 // we are holding i t o u r s e l f i f (RIGHT == true && LEFT == f a l s e ) { 345 turnonled ( 7 ) ; System. out. p r i n t l n ( Decided to put down r i g h t h a l f of keyboard! ) ; 347 RIGHT = f a l s e ; 349 // Send message to HOST app about keyboard a v a i l a b l e statusmsg = RIGHT f r e e + myaddr. asdottedhex ( ) ; 351 startsenderthread ( statusmsg ) ; 353 e l s e { System. out. p r i n t l n ( Right neighbor CS must c u r r e n t l y hold keyboard h a l f! ) ; 355 357 359 public void sw1opened ( ) { System. out. p r i n t l n ( Switch 1 opened. ) ; 361 363 public void sw2opened ( ) { System. out. p r i n t l n ( Switch 2 opened. ) ; 365 367 public void startsw1watchthread ( ) { new Thread ( ) { 369 public void run ( ) { while ( true ){ 371 sw1. waitforchange ( ) ; i f ( sw1. isclosed ( ) ) { 373 sw1closed ( ) ; 107

C.4. EXPERIMENT 3 - TWITTERINGCS-ONSPOT APPLICATION.JAVA APPENDIX C. SOURCE CODE e l s e { 375 sw1opened ( ) ; 377 379. s t a r t ( ) ; 381 public void startsw2watchthread ( ) { 383 new Thread ( ) { public void run ( ) { 385 while ( true ){ sw2. waitforchange ( ) ; 387 i f ( sw2. isclosed ( ) ) { sw2closed ( ) ; 389 e l s e { sw2opened ( ) ; 391 393. s t a r t ( ) ; 395 397 p r o t e c t e d void startapp ( ) throws MIDletStateChangeException { t r y { 399 initandrun ( ) ; catch ( IOException ex ) { //A problem in reading the sensors. 401 ex. p r i n t S t a c k T r a c e ( ) ; 403 405 protected void pauseapp ( ) { // This i s not c u r r e n t l y c a l l e d by the Squawk VM 407 409 / Called i f the MIDlet i s terminated by the system. 411 I. e. i f startapp throws any exception other than MIDletStateChangeException, i f the i s o l a t e running the MIDlet i s k i l l e d with I s o l a t e. e x i t ( ), or 413 i f VM. stopvm ( ) i s c a l l e d. 415 I t i s not c a l l e d i f MIDlet. notifydestroyed ( ) was c a l l e d. 417 @param unconditional I f true when t h i s method i s called, the MIDlet must cleanup and r e l e a s e a l l resources. I f f a l s e the MIDlet may throw 419 MIDletStateChangeException to i n d i c a t e i t does not want to be destroyed a t t h i s time. 421 / protected void destroyapp ( boolean unconditional ) throws MIDletStateChangeException 423 { // TODO 425 108

APPENDIX C. SOURCE CODE C.5. EXPERIMENT 3 - TWITTERINGCS-ONHOST SUNSPOTHOSTAPPLICATION.JAVA C.5 Experiment 3 - TwitteringCS-OnHost SunSpotHostApplication.java / S i d s e l Jensen <purps@diku. dk> 2 Experiment 3 : The t w i t t e r i n g Computer S c i e n t i s t s On HOST app I l l u s t r a t i o n of deadlocks and s t a r v a t i o n 4 / 6 package net. java. dev. netbeansspot ; 8 import com. sun. spot. p e r i p h e r a l. NoRouteException ; import java. net. HttpURLConnection ; 10 import java. net.url; import java. io. ; 12 import javax. microedition. io. Connector ; import javax. microedition. io. Datagram ; 14 import javax. microedition. io. DatagramConnection ; 16 import com. sun. spot. i o. j2me. radiogram. RadiogramConnection ; import com. sun. spot. io. j2me. radiostream. ; 18 import com. sun. spot. u t i l. U t i l s ; 20 import java. u t i l. logging. Level ; import java. u t i l. logging. Logger ; 22 import java. u t i l. ArrayList ; import java. u t i l. L i s t ; 24 import java. u t i l. StringTokenizer ; 26 public c l a s s SunSpotHostApplication { 28 p r i v a t e S t r i n g message = empty ; 30 p r i v a t e L i s t c l i e n t s = new ArrayList ( ) ; 32 p r i v a t e DatagramConnection dgbconn, dgclient = n u l l ; p r i v a t e boolean connected1, connected2, connected3, connected4 = f a l s e ; 34 p r i v a t e SpotRadio s p o t c l i e n t 1 = new SpotRadio ( ) ; p r i v a t e SpotRadio s p o t c l i e n t 2 = new SpotRadio ( ) ; 36 p r i v a t e SpotRadio s p o t c l i e n t 3 = new SpotRadio ( ) ; p r i v a t e SpotRadio s p o t c l i e n t 4 = new SpotRadio ( ) ; 38 p r i v a t e i n t port = 1 0 0 ; p r i v a t e i n t l a s t s p o t = 0 ; 40 // Set t w i t t e r login name and a u t h e n t i c a t i o n 42 // p r i v a t e S t r i n g screennames = CSsunspot ; // p r i v a t e S t r i n g authstring = SunSp0t ; 44 p r i v a t e S t r i n g screennames = sunspotdemo ; p r i v a t e S t r i n g authstring = c3vuc3bvdgrlbw86c29syxjpdw0 = ; 46 p r i v a t e s t a t i c f i n a l i n t INACTIVE = 0 ; 48 p r i v a t e s t a t i c f i n a l i n t CONNECTING = 1 ; p r i v a t e s t a t i c f i n a l i n t COMPLETED = 2 ; 109

C.5. EXPERIMENT 3 - TWITTERINGCS-ONHOST SUNSPOTHOSTAPPLICATION.JAVA APPENDIX C. SOURCE CODE 50 p r i v a t e s t a t i c f i n a l i n t IOERROR = 3 ; p r i v a t e s t a t i c f i n a l i n t PROTOCOLERROR = 4 ; 52 p r i v a t e s t a t i c i n t POSTstatus = INACTIVE ; 54 / 56 Posts a Twitter update. @param s t a t u s t e x t f o r the update 58 @param authstr a u t h e n t i c a t i o n c r e d e n t i a l s to use f o r HTTP POST / 60 synchronized public s t a t i c void posttwitterupdate ( S t r i n g status, S t r i n g authstr ) throws IOException { 62 HttpURLConnection conn = n u l l ; OutputStream out = n u l l ; 64 InputStream in = n u l l ; long s t a r t t i m e = 0 ; 66 S t r i n g resp = n u l l ; S t r i n g type = a p p l i c a t i o n /x www form urlencoded ; 68 S t r i n g u r l = http :// t w i t t e r. com/ s t a t u s e s /update. xml ; URL webaddr = new URL( u r l ) ; 70 System. out. p r i n t l n ( Posting : < + s t a t u s + > ); 72 t r y { POSTstatus = CONNECTING; 74 s t a r t t i m e = System. currenttimemillis ( ) ; conn = ( HttpURLConnection ) webaddr. openconnection ( ) ; 76 conn. setrequestmethod ( POST ) ; conn. setrequestproperty ( Content Type, type ) ; 78 conn. setrequestproperty ( Connection, c l o s e ) ; conn. setrequestproperty ( Authorization, Basic + authstr ) ; 80 conn. setdooutput ( true ) ; 82 out = conn. getoutputstream ( ) ; out. write ( ( s t a t u s = + s t a t u s + \n ). getbytes ( ) ) ; 84 out. f l u s h ( ) ; 86 in = conn. getinputstream ( ) ; resp = conn. getresponsemessage ( ) ; 88 i f ( resp. equals ( OK ) ) { POSTstatus = COMPLETED; 90 e l s e { POSTstatus = PROTOCOLERROR; 92 catch ( IOException ex ) { 94 POSTstatus = IOERROR ; ex. p r i n t S t a c k T r a c e ( ) ; 96 f i n a l l y { i f ( in!= n u l l ) in. c l o s e ( ) ; 98 i f ( out!= n u l l ) out. c l o s e ( ) ; // i f ( conn!= n u l l ) conn. c l o s e ( ) ; 100 102 i f ( POSTstatus! = COMPLETED) 110

APPENDIX C. SOURCE CODE C.5. EXPERIMENT 3 - TWITTERINGCS-ONHOST SUNSPOTHOSTAPPLICATION.JAVA System. out. p r i n t l n ( Posting f a i l e d : + resp ) ; 104 System. out. p r i n t l n ( Total time to post + ( including connection s e t up ) : + 106 ( System. currenttimemillis ( ) s t a r t t i m e ) + ms ) ; System. out. f l u s h ( ) ; 108 110 synchronized public void sendmessage ( S t r i n g m, S t r i n g IEEEaddress ){ 112 t r y { dgclient = 114 ( DatagramConnection ) Connector. open ( radiogram :// + IEEEaddress + : 3 7 ) ; catch ( IOException ex ) { 116 System. out. p r i n t l n ( Could not open radiogram connection to c l i e n t ) ; ex. p r i n t S t a c k T r a c e ( ) ; 118 return ; 120 t r y { 122 Datagram c l i e n t r e p l y = dgclient. newdatagram ( dgclient. getmaximumlength ( ) ) ; c l i e n t r e p l y. writeutf (m) ; 124 dgclient. send ( c l i e n t r e p l y ) ; dgclient. c l o s e ( ) ; 126 catch ( IOException ex ) { ex. p r i n t S t a c k T r a c e ( ) ; 128 130 synchronized public void sendbroadcastmessage ( S t r i n g m){ 132 t r y { i f ( dgbconn == n u l l ) dgbconn = 134 ( DatagramConnection ) Connector. open ( radiogram :// broadcast : 3 7 ) ; catch ( IOException ex ) { 136 System. out. p r i n t l n ( Could not open radiogram broadcast connection ) ; ex. p r i n t S t a c k T r a c e ( ) ; 138 return ; 140 t r y { Datagram dg = dgbconn. newdatagram ( dgbconn. getmaximumlength ( ) ) ; 142 dg. writeutf (m) ; dgbconn. send ( dg ) ; 144 catch ( IOException ex ) { ex. p r i n t S t a c k T r a c e ( ) ; 146 148 public void a l i v e s p o t s ( ) { 150 S t r i n g caddress = n u l l ; 152 t r y { RadiogramConnection conn = 154 ( RadiogramConnection ) Connector. open ( radiogram : / / : 3 7 ) ; Datagram dgreply = conn. newdatagram ( conn. getmaximumlength ( ) ) ; 111

C.5. EXPERIMENT 3 - TWITTERINGCS-ONHOST SUNSPOTHOSTAPPLICATION.JAVA APPENDIX C. SOURCE CODE 156 System. out. p r i n t l n ( Sending broadcast ping to c l i e n t s ) ; 158 sendbroadcastmessage ( Ping? ) ; 160 // loop f o r as long as timeout value i s valid f o r... while ( true ) { 162 conn. settimeout ( 5 0 0 ) ; conn. r e c e i v e ( dgreply ) ; 164 S t r i n g question = dgreply. readutf ( ) ; S t r i n g portnumber = ; 166 i f ( question. equals ( I am a l i v e ) ) { 168 // f e t c h address from c l i e n t spot caddress = dgreply. getaddress ( ) ; 170 // check i f we already have t h a t c l i e n t in the l i s t i f ( c l i e n t s. contains ( caddress )!= true ) { 172 // i f not put c l i e n t address in c l i e n t l i s t c l i e n t s. add ( caddress ) ; 174 System. out. p r i n t l n ( Added new c l i e n t to l i s t : + caddress ) ; port = 100 + c l i e n t s. indexof ( caddress ) ; 176 portnumber = I n t e g e r. t o S t r i n g ( port ) ; sendmessage ( portnumber, caddress ) ; 178 System. out. p r i n t l n ( Sent portnumber + portnumber + to c l i e n t : + caddress ) ; 180 e l s e { System. out. p r i n t l n ( C l i e n t already added to l i s t! ) ; 182 e l s e { 184 System. out. p r i n t l n ( I n c o r r e c t reply from c l i e n t ) ; 186 dgreply. r e s e t ( ) ; 188 catch ( IOException e ) { System. out. p r i n t l n ( C l i e n t closed connection ) ; 190 f i n a l l y { //conn. c l o s e ( ) ; 192 194 public S t r i n g firstword ( S t r i n g s ) { 196 S t r i n g firstword = ; 198 i n t spaceindex = s. indexof ( ) ; i f ( spaceindex == 1) { 200 firstword = s ; e l s e { 202 firstword = s. substring ( 0, spaceindex ) ; 204 //System. out. p r i n t l n ( F i r s t word in message i s : + firstword ) ; return firstword ; 206 208 public S t r i n g secondword ( S t r i n g s ) { 112

APPENDIX C. SOURCE CODE C.5. EXPERIMENT 3 - TWITTERINGCS-ONHOST SUNSPOTHOSTAPPLICATION.JAVA S t r i n g firstword = ; 210 S t r i n g secondword = ; StringTokenizer s t = new StringTokenizer ( s ) ; 212 i f ( s t. counttokens ( ) > 1) { 214 firstword = s t. nexttoken ( ) ; secondword = s t. nexttoken ( ) ; 216 //System. out. p r i n t l n ( Second word in message i s : + secondword ) ; 218 return secondword ; 220 public S t r i n g lastword ( S t r i n g s ) { 222 S t r i n g lastword = ; 224 i n t spaceindex = s. indexof ( ) ; i f ( spaceindex == 1) { 226 lastword = s ; e l s e { 228 lastword = s. substring ( s. lastindexof ( ) + 1 ) ; 230 //System. out. p r i n t l n ( Last word in message i s : + lastword ) ; 232 return lastword ; 234 synchronized public void 236 startreceiverthread ( f i n a l S t r i n g address, f i n a l i n t c l i e n t ) { new Thread ( ) { 238 public void run ( ) { 240 i f ( c l i e n t == 0) { i f (! connected1 ) { 242 s p o t c l i e n t 1. connect ( address, c l i e n t ) ; connected1 = true ; 244 message = s p o t c l i e n t 1. r e c e i v e ( ) ; 246 e l s e i f ( c l i e n t == 1) { 248 i f (! connected2 ) { s p o t c l i e n t 2. connect ( address, c l i e n t ) ; 250 connected2 = true ; 252 message = s p o t c l i e n t 2. r e c e i v e ( ) ; 254 e l s e i f ( c l i e n t == 2) { i f (! connected3 ) { 256 s p o t c l i e n t 3. connect ( address, c l i e n t ) ; connected3 = true ; 258 message = s p o t c l i e n t 3. r e c e i v e ( ) ; 260 e l s e i f ( c l i e n t == 3) { 113

C.5. EXPERIMENT 3 - TWITTERINGCS-ONHOST SUNSPOTHOSTAPPLICATION.JAVA APPENDIX C. SOURCE CODE 262 i f (! connected4 ) { s p o t c l i e n t 4. connect ( address, c l i e n t ) ; 264 connected4 = true ; 266 message = s p o t c l i e n t 4. r e c e i v e ( ) ; 268 e l s e { System. out. p r i n t l n ( C l i e n t l i s t not long enough! ) ; 270 272. s t a r t ( ) ; 274 276 synchronized public void startsenderthread ( f i n a l S t r i n g msg, f i n a l S t r i n g address, f i n a l i n t c l i e n t ) { 278 new Thread ( ) { public void run ( ) { 280 t r y { 282 i f ( c l i e n t == 0) { i f (! connected1 ) { 284 s p o t c l i e n t 1. connect ( address, c l i e n t ) ; connected1 = true ; 286 s p o t c l i e n t 1. send (msg ) ; 288 e l s e i f ( c l i e n t == 1) { 290 i f (! connected2 ) { s p o t c l i e n t 2. connect ( address, c l i e n t ) ; 292 connected2 = true ; 294 s p o t c l i e n t 2. send (msg ) ; 296 e l s e i f ( c l i e n t == 2) { i f (! connected3 ) { 298 s p o t c l i e n t 3. connect ( address, c l i e n t ) ; connected3 = true ; 300 s p o t c l i e n t 3. send (msg ) ; 302 e l s e i f ( c l i e n t == 3) { 304 i f (! connected4 ) { s p o t c l i e n t 4. connect ( address, c l i e n t ) ; 306 connected4 = true ; 308 s p o t c l i e n t 4. send (msg ) ; 310 e l s e { System. out. p r i n t l n ( C l i e n t l i s t not long enough! ) ; 312 314 catch ( IOException ex ) { 114

APPENDIX C. SOURCE CODE C.5. EXPERIMENT 3 - TWITTERINGCS-ONHOST SUNSPOTHOSTAPPLICATION.JAVA Logger. getlogger ( SunSpotHostApplication. c l a s s. getname ( ) ). log ( Level. SEVERE, null, ex ) ; 316 318. s t a r t ( ) ; 320 322 public void initandrun ( ) { S t r i n g l e f t n e i g h b o r = ; 324 S t r i n g rightneighbor = ; S t r i n g incomingmsg = ; 326 S t r i n g spot = ; S t r i n g a v a i l a b l e = ; 328 i n t i, j = 0 ; i n t rn = 0 ; // index number of r i g h t neighbor 330 i n t ln = 0 ; // index number of l e f t neighbor 332 // E s t a b l i s h how many c l i e n t s we are t a l k i n g to... 334 a l i v e s p o t s ( ) ; l a s t s p o t = c l i e n t s. s i z e ( ) 1; 336 while ( true ) { 338 // check our c l i e n t s in a round robin fashion // f o r each c l i e n t in our l i s t do... 340 f o r ( i = 0 ; i < c l i e n t s. s i z e ( ) ; i ++ ) { 342 //System. out. p r i n t l n ( Current c l i e n t address : + c l i e n t s. get ( i ) ) ; //System. out. p r i n t l n ( P r i n t i : + I n t e g e r. t o S t r i n g ( i ) ) ; 344 //System. out. p r i n t l n ( Current c l i e n t address : + c l i e n t s. get ( i ) ) ; 346 // Receive message from spots startreceiverthread ( ( S t r i n g ) c l i e n t s. get ( i ), i ) ; 348 // U t i l s. sleep ( 2 0 0 ) ; 350 // I f the message i s empty don t p r i n t i t i f (! message. equalsignorecase ( ) ) { 352 System. out. p r i n t l n ( Received message : + message ) ; 354 incomingmsg = firstword ( message ) ; 356 spot = lastword ( message ) ; a v a i l a b l e = secondword ( message ) ; 358 // 3 d i f f e r e n t incoming messages : i f ( incomingmsg. equalsignorecase ( RIGHT ) ) { 360 // RIGHT taken // send msg to r i g h t neighbor c l i e n t +1 to turn o f f LEFT LED 362 i f ( a v a i l a b l e. equalsignorecase ( taken ) ) { // i s i t the l a s t spot in our index? 364 i f ( c l i e n t s. indexof ( spot ) == l a s t s p o t ) { startsenderthread ( turn l e f t o f f, ( S t r i n g ) c l i e n t s. get ( 0 ), 0 ) ; 366 e l s e { rn = c l i e n t s. indexof ( spot ) ; 115

C.5. EXPERIMENT 3 - TWITTERINGCS-ONHOST SUNSPOTHOSTAPPLICATION.JAVA APPENDIX C. SOURCE CODE 368 rn ++; rightneighbor = ( S t r i n g ) c l i e n t s. get ( rn ) ; 370 startsenderthread ( turn l e f t o f f, rightneighbor, rn ) ; 372 // RIGHT f r e e // send msg to r i g h t neighbor to turn on LEFT LED 374 e l s e i f ( a v a i l a b l e. equalsignorecase ( f r e e ) ) { i f ( c l i e n t s. indexof ( spot ) == l a s t s p o t ) { 376 startsenderthread ( turn l e f t on, ( S t r i n g ) c l i e n t s. get ( 0 ), 0 ) ; e l s e { 378 rn = c l i e n t s. indexof ( spot ) ; rn ++; 380 rightneighbor = ( S t r i n g ) c l i e n t s. get ( rn ) ; startsenderthread ( turn l e f t on, rightneighbor, rn ) ; 382 e l s e { 384 System. out. p r i n t l n ( I n v a l i d second word ) ; 386 e l s e i f ( incomingmsg. equalsignorecase ( LEFT ) ) { // LEFT taken 388 // send msg to l e f t neighbor c l i e n t 1 to turn o f f RIGHT LED i f ( a v a i l a b l e. equalsignorecase ( taken ) ) { 390 // i s t h i s the f i r s t spot in our index? i f ( c l i e n t s. indexof ( spot ) == 0) { 392 startsenderthread ( turn r i g h t o f f, ( S t r i n g ) c l i e n t s. get ( l a s t s p o t ), l a s t s p o t ) ; e l s e { 394 ln = c l i e n t s. indexof ( spot ) ; ln ; 396 l e f t n e i g h b o r = ( S t r i n g ) c l i e n t s. get ( ln ) ; startsenderthread ( turn r i g h t o f f, l e f t n e i g h b o r, ln ) ; 398 // LEFT f r e e 400 // send msg to l e f t neighbor to turn on RIGHT LED e l s e i f ( a v a i l a b l e. equalsignorecase ( f r e e ) ) { 402 i f ( c l i e n t s. indexof ( spot ) == 0) { startsenderthread ( turn r i g h t on, ( S t r i n g ) c l i e n t s. get ( l a s t s p o t ), l a s t s p o t ) ; 404 e l s e { ln = c l i e n t s. indexof ( spot ) ; 406 ln ; l e f t n e i g h b o r = ( S t r i n g ) c l i e n t s. get ( ln ) ; 408 startsenderthread ( turn r i g h t on, l e f t n e i g h b o r, ln ) ; 410 e l s e { System. out. p r i n t l n ( I n v a l i d second word ) ; 412 // TWEET :... 414 // Send message to t w i t t e r! e l s e i f ( incomingmsg. equalsignorecase ( TWEET: ) ) { 416 t r y { posttwitterupdate ( message, authstring ) ; 418 catch ( IOException ex ) { Logger. getlogger ( SunSpotHostApplication. c l a s s. getname ( ) ). log ( Level. SEVERE, null, ex ) ; 420 116

APPENDIX C. SOURCE CODE C.5. EXPERIMENT 3 - TWITTERINGCS-ONHOST SUNSPOTHOSTAPPLICATION.JAVA // and give msg to both neighbors to turn LEDs back ON 422 i f ( c l i e n t s. indexof ( spot ) == 0) { startsenderthread ( turn r i g h t on, ( S t r i n g ) c l i e n t s. get ( l a s t s p o t ), l a s t s p o t ) ; 424 startsenderthread ( turn l e f t on, ( S t r i n g ) c l i e n t s. get ( 1 ), 1 ) ; e l s e i f ( c l i e n t s. indexof ( spot ) == l a s t s p o t ) { 426 startsenderthread ( turn l e f t on, ( S t r i n g ) c l i e n t s. get ( 0 ), 0 ) ; ln = c l i e n t s. indexof ( spot ) ; 428 ln ; l e f t n e i g h b o r = ( S t r i n g ) c l i e n t s. get ( ln ) ; 430 startsenderthread ( turn r i g h t on, l e f t n e i g h b o r, ln ) ; e l s e { 432 ln = c l i e n t s. indexof ( spot ) ; ln ; 434 l e f t n e i g h b o r = ( S t r i n g ) c l i e n t s. get ( ln ) ; startsenderthread ( turn r i g h t on, l e f t n e i g h b o r, ln ) ; 436 rn = c l i e n t s. indexof ( spot ) ; rn ++; 438 rightneighbor = ( S t r i n g ) c l i e n t s. get ( rn ) ; startsenderthread ( turn l e f t on, rightneighbor, rn ) ; 440 442 //System. out. p r i n t l n ( I d l e away.... ) ; 444 incomingmsg = ; message = ; 446 U t i l s. sleep ( 2 0 0 ) ; 448 i = 0 ; 450 452 public s t a t i c void main ( S t r i n g [ ] args ) { SunSpotHostApplication App = new SunSpotHostApplication ( ) ; 454 App. initandrun ( ) ; 456 117

C.5. EXPERIMENT 3 - TWITTERINGCS-ONHOST SUNSPOTHOSTAPPLICATION.JAVA APPENDIX C. SOURCE CODE 118

Appendix D Video transcriptions (in Danish) D.1 Transcription of TA test 5 people present: Teacher/Interviewer/Observer SB1: Subject 1 (HTX) SB2: Subject 2 (HTX) SB3: Subject 3 (DIKU) and 1 person responsible for the video-recording (silent). Setup: Teacher handed out paper descriping the experiment and gave small introduction to the experiment. Test subjects start reading the experiment text, they then proceed to discussing how they perceive the assignment. (The following is in Danish) SB2: Der sidder 5 mennesker ikke? Men der er kun 4 keyboards ikke? Der er et keyboard mellem dem? SB3: Der er et halvt keyboard mellem hver person. Altså hvis vi sidder sådan her så er der et halvt keyboard her, og et halvt keyboard her (viser med hænderne på hver side af sig selv). Så har du også et halvt et, derovre (peger). SB2: Ligger der et halvt keyboard på hver side af en person? SB3: Jo, præcis sådan så hver har et helt et, bortset fra at de skal dele. SB2: Hmm ok men svarer det ikke til at der står et helt keyboard i mellem dem, 119

D.1. TRANSCRIPTION OF TA APPENDIX TEST D. VIDEO TRANSCRIPTIONS (IN DANISH) men så har man kun halvdelen? SB3: Nej, der er kun et halvt. Der er ikke et helt som man deler. Pointen er jo lidt, at hvis du har et helt på hver side, så ville du ikke have et behov for at skulle dele. SB3: Nå ok og så fungerer det her (peger på SunSPOTen) som keyboardet. Nå nej, det er personerne. SB2: Og så er problemet at de allesammen tager fat i den venstre halvdel af keyboardet? SB1: Problemet er vel at der ikke er nogen bestemt rækkefølge, som de tager deres del af tastaturet på. Man ved aldrig hvem der tager først. SB3: (Læser op af teksten..) Nå ok helt sikkert - sådan de to knapper er så hvilken af de to ressourcer man skal bruge. Eller om man ikke skal bruge en af dem. Fordi man regner med at de andre skal bruge en af dem. SB2: Ja og hvis man klikker på den, så frigiver man den. SB3: Ja, det tror jeg også (læser videre griner lidt) Teacher bryder ind: Altså det første vi skal, er at vi skal have opgraderet dem her (tager en SunSPOT). Det gør I ved at koble dem til her (sætter USB kablet i). Kan I allesammen se nu? Det er lidt nemmere, hvis I alle sammen kan se skærmen. Hernede kan man så vælge upgrade. Den upgrader jo så til den samme firmware som den allerede har, men den laver så et nøglepar, som gør at... SB3: Nøglen den kommer fra masteren? Teacher: Så siger, den så lige at du skal resette den. SB3: Hvad er det primært der bliver testet? Er det SunSPOTen eller er det concurrency? Teacher: Det er concurrency... Teacher: Nu skal I se, heroppe kan I se mac-adressen på SunSPOTen, der sidder sluttet til lige nu. SB3: Hvor kan du se det henne? Teacher: Adressen står oppe ved radioen (viser hvor). SB3: Hvorfor uploader den flere filer? 120

APPENDIX D. VIDEO TRANSCRIPTIONS (IN DANISH) D.1. TRANSCRIPTION OF TA TEST Teacher: Fordi den uploader firmwaren. SB2: Hvorfor er det lige at den skal have den nøgle? Teacher: Det er fordi at hvis du er i et lab-miljø hvor du har rigtig mange SunSPOTs, så er du ikke interesseret i at der er nogle andre der kan overtage eller hijacke dine SunSPOTs og f.eks. Lægge et andet program på dem, hvis du er igang med at kører et eller andet. Så du laver en SSH nøgle, som gør at din desktop maskine og dine SunSPOTs passer sammen. Så du har kun lov til at rette i de SunSPOTs som du har nøglen til. SB2: Smart Teacher: Det her skal I så gøre for alle 4, så kan I så lægge programmet over på bagefter. SB3: Findes der nogle protokoller til at udbrede programmer på dem altså sådan en mesh-model? Teacher: Det viste jeg jer slet ikke, men det understøtter den også. Altså hvis du har base stationen tilkoblet... SB3: Altså hvis nu man har 100 og ikke gider at opdatere dem allesammen? Teacher: Så skriver du ant deploy -DremoteId og så mac-adressen. Og så står man typisk i det katalog for det program man gerne vil deploye, så sender den programmet via base stationen direkte til den spot SB3: Nå ok cool. Men jeg tænker lidt på om man kan sprede et program ud altså sender den til en og så... Teacher: Tænker du på noget flooding? SB3: Ja, og om den så lige checker og siger hey jeg har fået et nyt program og så sender den det videre? Teacher: Det ved jeg faktisk ikke dvs. Jeg har ikke set det. De har jo lavet det sådan så du kan sende programmet direkte det vil jo typisk belaste dit netværk mindre. SB2: Den er færdig. Teacher: Ja, så kan I tage den af og så sætte den næste på. Den her (peger) har lidt problemer med batteriet, så når I laver forsøget, skal I nok sørge for at have den koblet direkte på (med USB kabel). 121

D.1. TRANSCRIPTION OF TA APPENDIX TEST D. VIDEO TRANSCRIPTIONS (IN DANISH) SB3: Men vi er jo også kun 3 personer lige nu Teacher: Men det gør jo ikke noget, I kan jo sagtens lægge programmet over på fire. (de fortsætter med at opgradere firmware på de øvrige SunSPOTs) SB3: Server-dimsen er bare sådan et stand-alone program? Teacher: Ja SB3: Du sagde at den her havde et problem med batteriet? Hvad betyder det helt præcist sidder det løst eller at det har en dårlig levetid? Teacher: Jeg kan ikke finde ud af, om den ikke lader på det. SB3: Kan man bare bruge den, mens den sidder med USB-kablet i? Teacher nikker SB3: Så stod der noget med at man skulle tænde dem her først, før man starter hostprogrammet? Teacher: Nu har I opgraderet dem så nøglerne passer, nu skal I så have lagt programmet over på dem. (viser i Netbeans hvordan programmet lægges på) (de fortsætter med at lægge programmerne over på de enkelte spots) Teacher: Og det I så gør nu, er at I kan skrive ant run, på den der er forbundet. Og så skal I lige resette dem allesammen for at starte programmet automatisk. Så lige om lidt, så kan I se at den kommer op her. Nu siger den hej min adresse er, jeg venter nu på base stationen. SB3: Så får de allesammen sådan en lys-diode i hver side eller hvad? Teacher: Nu skal I så starte base stations programmet. SB3: Ah yes. Den bruger så bare base stationen som radio sender? SB3: Ta-da så skete der noget...så har vi nogle ressourcer SB3: Nå ok (de arrangerer dem på bordet) 122

APPENDIX D. VIDEO TRANSCRIPTIONS (IN DANISH) D.1. TRANSCRIPTION OF TA TEST Teacher: Måske kan I prøve at starte med at finde ud af hvem der er nabo til hvem. (de bytter lidt rundt på spotsne så de ligger rigtigt i en cirkel) SB3: Yes. Ok så hvis nu jeg starter med at trykke på denne her (de sorterer dem færdig). Så er den nabo med den. Så kan vi lægge dem sådan her. SB2: De her to ligger rigtigt SB1: Nu ligger de vist meget rigtigt SB3: Yes SB2: Nå hvad skulle vi så? SB3: Øhm - Så er det noget med, at hvis der er en der har allokeret sådan her (trykker på en SunSPOT knap og så en til). Sådan her og sådan der nå (spørgende). SB1: Ah det er fordi den skriver til twitter så snart du trykker på begge ressourcer. SB3: Men når jeg trykker på den ene og så på den anden, så bliver de begge to deallokeret SB2: Når de lyser, er det så fordi de er allokeret, eller at de er ledige? SB1: Så er de ledige SB3: Nåh der er ihvertfald blevet twitteret kan jeg se ja, for 20 sekunder siden. How ever that happened nååh OK det er rigtig Twitter hjemmesiden twitter twitter/- sunspotdemo SB3: OK tror I så ikke at det er sådan at enten skal man trykke på dem begge to eller også skal man kun trykke på den ene af dem og når man så trykker på den anden, så laver den et tweet. SB1 og SB2: Jo SB2: Hvad hvis nu du prøver at tage den, der er væk nu? (henvendt til SB1). Nå så sker der bare ikke noget. SB3: Nå okay Teacher: Det er dem hvor den skriver Tweet kolon og så et eller andet bagefter, for der er nogle andre der bruger siden til noget andet 123

D.1. TRANSCRIPTION OF TA APPENDIX TEST D. VIDEO TRANSCRIPTIONS (IN DANISH) SB3: Ok så hedder de noget forskelligt? Eller er det bare noget tilfældigt output Teacher: Den har mac-adressen med, så I kan se hvilke der er jeres. SB3: Prøv du lige at trykke.. (henvendt til SB2) SB3: (Kigger på skærmen) Nå man kan også se en log-fil her, for hvad der bliver tweetet SB3: Så hvem af os, er det, der har lånt det her keyboard. Var det dig? SB2: Øh sgu ikke mere. (de trykker lidt frem og tilbage) SB3: Arhh give me... SB1: Der fik den tweetet SB1: Hvis vi nu prøver at du tager den ene halvdel der (henvendt til SB3) og tager den anden halvdel her (peger på anden SunSPOT). SB3: Så tager jeg denne her SB1: Hvad sker der så? SB3: Jammen, det kan jeg ikke (prøver at tage deallokeret keyboard). Så venter den. Hvad skal vi prøve at lave en løkke? Prøv du at sige at du vil have den der (rettet til SB2) og at du vil have den der (peger mod SB1). Og så noooooooo (der er nu ingen ledige ressourcer) SB3: Nej nej, så prøv at trykke på den, så laver du et tweet SB1: Så trykker jeg på denne her, så laver jeg et tweet SB3: Ja og så trykker jeg her sådan der. Og nu kan jeg også. Men det var fordi der var en af os, der fik en ledig en ikke? Skal vi prøve at lave den igen? SB2: Hov, der tweetede den SB3: okay og nu er jeg locked argh. Nå det er dig der har stjålet den der. Sådan der så nu er den locked igen. Lægger programmet mærke til det? Næh vel, den venter 124

APPENDIX D. VIDEO TRANSCRIPTIONS (IN DANISH) D.1. TRANSCRIPTION OF TA TEST bare. Cool. SB3: Okay jeg frigiver næh det kan jeg ikke SB1: Den er låst derfra (peger mod nabo SunSPOT). Kan vi lave en situation, hvor der er en af dem, der slet ikke kan noget som helst? SB3: Ja, det kan man, hvis de to omkring den der tager ressourcerne. Sådan der og sådan der, så nu kan jeg ikke gøre noget jeg er udelukket. Men du kan tweete ved at tage ressourcen. Men du kan ikke blokkere dem begge to, for så frigiver de ressourcerne efterfølgende. (de roder lidt videre ved at trykke på knapperne) SB2: Nu har de så tweetet helt ekstremt. Er det bare helt tilfældigt hvad der kommer frem der? SB3: Det ved jeg ikke. Teacher: Twitter er så smart til forskel fra facebook, så hvis du bare sender dem samme linie to gange til facebook så poster den det jo. Twitter sorterer dem fra så du kan ikke sende den samme linie to gange, så jeg var nød til at lave noget, der var lidt random for ellers var der simpelthen noget der ikke kom med. (de trykker videre) SB2: Så nu er der en, der ikke kan noget SB3: Nej, nej der er ingen af os der kan noget andet end at frigive en af vores højre ressourcer SB1: Det sidste der står er så Try to come up with a solution to the problem an algorithm that guarantees that all computer scientists gets to twitter at some point (læser op af experiment teksten). SB3: Nå ok. En lidt fjollet måde, er at låse dem allesammen først og så aflåse dem igen. Hvis nu vi starter med at gøre det her (trykker på en spot), og så gør det her (trykker videre til de har en deadlock). Så gør jeg sådan her og så trykker du på den der i modsætning og så kan du unlåse og får vi allesammen gjort det i træk. Altså hvis du bruger ressourcen snarer end at frigøre den, så bliver de begge to ulåste. Så altså hvis man skulle beskrive det som en algoritme, så kunne jeg starte med at højrelåse, men når den her (peger med venstre led) bliver taget så frigiver jeg min lås igen. Det er så den ene halvdel af det. Den anden halvdel er så, at når den anden bliver frigjort, så 125

D.1. TRANSCRIPTION OF TA APPENDIX TEST D. VIDEO TRANSCRIPTIONS (IN DANISH) bruger jeg den. Forstår I? Så det er sådan en todelt algoritme. (herefter afprøver de strategien) SB3: Så nu låser vi dem. Så den her anden del med den her er så at hov nu blev den taget, så nu frigiver jeg min. Og så er din anden del af algoritmen, at nu får du en ressource, så bruger du den. Og så får vi allesammen twitteret i træk. Det er ihvertfald en løsning. (de afprøver strategien videre) SB3: Men hov kunne der ikke opstå et problem hvor at hvis du bruger din ressource igen, før jeg når at få allokeret den, så får alle lov undtagen ham der starter. Men så kunne man skiftes om det. Så hvis man det kunne man også indbygge så kunne man gøre et eller andet med at hvis nu det var mig der gjorde det her med at jeg kan se at der er to ressourcer fri, og jeg så bare allokerer en og venter så hvis jeg lige har gjort det så tænker jeg okay - at hvis de andre nu er så ivrige efter at få et af de der tastaturer, at jeg regner slet ikke med at jeg får min tur denne her gang, fordi det er mig der skal starte den her iteration, så hvis bare jeg sørger for at det ikke er mig, der starter næste gang så får jeg lov til at twittere næste gang og så i en hel cyklus hvor man starter med at skiftes så får man twitteret 3 gange ud af fire. Garanteret. Og så kan man ligesågodt bare skyde den sidste. SB1: Så er det bare synd for ham. Og den sidste der twitter, det er så ham der låser... SB3: Ja ham der begynder, nej undskyld den sidste der twitter han er garanteret for ivrig alligevel. Og det kan man ikke man har kun de der tastaturer til at kommunikerer med. Nå det er ihvertfald en måde tænker jeg jeg ved ikke om at man gøre det på andre måder. Det var ihvertfald den måde der lige gik op for mig, da vi sad og gjorde det her. SB2: Smart Teacher: Nu har I selvfølgelig et lige antal (SunSPOTs), man kunne jo godt have forestillet sig at det var et ulige antal. Kunne I så have gjort noget mere hvis det var parvis eller? SB2: Kan man tage en fra, så der kun er tre? Teacher: Det kan I godt I kan bare slukke en af dem. Men det kræver at I genstarter programmet. Fordi den laver en klient liste over hvormange klienter der er. SB3: Vi kunne også bare lade som om nå nej det kan vi ikke. Uhmmm... 126

APPENDIX D. VIDEO TRANSCRIPTIONS (IN DANISH) D.1. TRANSCRIPTION OF TA TEST Teacher: Men vi kan da bare starte programmet forefra hvis I vil det. (viser hvordan man stopper programmet og starter det igen) SB3: (taler højt for sig selv)twittering philosophers embedded twittering philosophers SB2: Passer det så nu med rækkefølgen? Nej (de sorterer spotsne igen) SB3: Yes. Okay. SB2: Vil det ikke give et problem når det er ulige? SB3: Uhmmm nej det tror jeg ikke, så længe at der er en ring rundt om bordet. Men altså hvis man lavede en metode som afhang af par vil det give et problem, tror jeg, når man er ulige. Øhm... SB2: Hvad hvis vi gjorde det på den der venlige måde, at hvis ikke man kunne noget så frigav man sin ressource. SB3: Det kan vi godt prøve. Jeg starter bare fordi jeg er den første. Man kan vel sige - det er vel egentlig først rigtig spændende hvad man gør for at håndtere for at undgå en deadlock. Så hvis nu vi prøver at lave en deadlock. Hvad gør man så hvis man har en ressource, men ikke kan få den anden? Hvis nu man var venlig så sker der potentielt det, at alle er venlige samtidig. SB2: Men så er vi jo tilbage? SB3: Jo så kan du bruge dine ressourcer. SB3: Øhmm Sidsel sagde noget om at man kunne bruge tilfældighed altså hvis alle er lige hurtige til at være høflige hvorimod hvis alle er høflige efter et bestemt tidspunkt som er tilfældigt, så er det sjældent at sandsynligheden for at der opstår den samme deadlock to gange i træk. SB1: Det man så kunne gøre var at hver af enhederne med et tilfældigt interval ville forsøge at anskaffe sig begge ressourcer. SB3: Tja, det ved jeg ikke vi kunne også forestille os, at de egentlig bare gerne ville tweete med et bestemt tempo. Teacher: Kunne man måske forestille sig, at der var en der gerne ville tweete oftere end andre altså en der var grådig? 127

D.1. TRANSCRIPTION OF TA APPENDIX TEST D. VIDEO TRANSCRIPTIONS (IN DANISH) SB2: Det der med at man parrede dem. Var problemet så ikke at hvis der kun var to, og jeg f.eks. Tog den højre først og Jonas vælger den venstre først, så er vi deadlocket? Teacher: Men der er jo ikke nogen der siger at man altid skal tage den højre side af keyboardet først. SB2: Men øger det chancen for deadlocks hvis man altid tager den samme side først? SB3: det kommer vel an på hvad de andre gør? Teacher: Hvis der nu er en der altid tager den venstre hver gang, når de andre tager den højre vil det så kunne forhindre deadlocks? SB2: Det ved jeg ikke - skal vi prøve? SB3: Jeg tager den ventre først, så kan I prøve at tage den højre. (de afprøver strategien) SB3: Det er lidt svært at forestille sig hvad konsekvensen er. Men hvis nu man havde en aftale om at alle tweetede med samme tempo. Ikke nødvendigvis at der var præcis sammenfald, men altså der er ikke nogen der er mere ivrig end andre. Hvad skulle man gøre i sådan en situation? (de afprøver strategien videre) SB3: Altså hvis jeg går imod strømmen, så ham der sidder før mig, han bliver totalt snydt nogen gange. Med mindre hov hvis du rent faktisk nåede at tage din højre først, altså før jeg tog min venstre så vil jeg ikke hvis det er mig der går mod strømmen (de tester videre). Men det er ikke som om der er nogen garanti vel? Fordi det afhænger meget af hvem af os to - at vi konkurrerer om at få den fordi jeg går imod strømmen. I tilfælde af du får den først, så er det dig der tweeter, og hvis det er mig der får den så er det mig der tweeter. Det kan være at der er noget at sige om hvem der får startet eller om det bare er en der griber den. SB1: Hvad sker der hvis alle prøver at tweete samtidig? Hvis alle tager den venstre? SB3: Så er der deadlock igen. (de tester det af) 128

APPENDIX D. VIDEO TRANSCRIPTIONS (IN DANISH) D.1. TRANSCRIPTION OF TA TEST SB3: Jeg tror stadigvæk at min første forslag ville virke, men jeg tror måske at der er nogle problemer med at hvis alle skal vente helt vildt meget det tror jeg måske er en praktisk ulempe der kan gøre rigtig meget. Teacher: Så længe, at det ikke er uendeligt...så gør det vel ikke noget? SB1: Når man ikke fysisk skal trykke på en knap så går det jo meget hurtigere. SB3: Men det lidt ligesom, hvis denne her skal sige noget til den her, som skal sige noget til den her så jo større ringen bliver så tager det længere tid for det, at propagere det rundt. Før den første kan gå igang igen. Så kan to der burde kunne sidde og tweete samtidig det gør de ikke fordi man har serialiseret det. SB1: Men kunne man så ikke lave det i par? (viser med hænderne hvad han mener) SB3: Det kunne vi godt prøve og så se hvad der sker. Skal vi prøve at resette det hele igen? SB1 og SB2: Ja SB3: Så kan vi prøve at se hvad der sker når de støder på hinanden fordi, der ikke er perfekt timing. (de resetter forsøget) SB2: Hvad hvis man nu kun allokerede en ressource? SB3: Hvad mener du? Så får man jo ikke rigtig noget ud af det for man skal jo bruge begge to? (forsøget er nu resat med 4 SunSPOTs igen) SB3: Hvad var det så vi ville teste? SB1: Altså istedet for en cirkel, kunne man lade dem gå i par i en cirkel. SB3: Altså den overfor? SB1: Ja, jeg tror det skalerer bedre SB3: Ja, helt sikkert. Altså hvis jeg nu starter med at tage min højre ressource, så ved den (peger på naboen), at nej det er sådan lidt shaky. Hvis nu hver anden er flink og hver anden er aggresiv men så får de ikke allesammen tweetet lige meget hvis det 129

D.2. TRANSCRIPTION OF SMALL-TALK APPENDIX D. AFTER VIDEOTA TRANSCRIPTIONS (IN DANISH) er en faktor i det. Hvis nu det var rent praktisk, så ville man måske fordele folk på en sådan måde at de folk der tweeter meget lidt, kan sætte sig ved siden af de folk der tweeter meget, for så kan de dele ressourcerne bedre. Altså ligesom hvis man sætter venstre-holdet ved siden af hinanden, så de ikke skubber albuerne ind i hinanden. Teacher: Men det kræver at du ved noget om folks behov på forhånd ikke? SB3: Jo, det er rigtigt. SB1: Altså hvis der ikke var grådighed så var løsningen jo bare at hvis man ser at en ressource er blevet taget så skal man jo bare ikke tage den anden ressource, selvom man godt kan. Teacher: Der er mange muligheder men jeg tror at vi skal stoppe her? (De har på dette tidspunkt brugt ca. 1 time på opgaven) D.2 Transcription of Small-talk after TA 5 people present: Teacher/Interviewer/Observer SB1: Subject 1 (HTX) SB2: Subject 2 (HTX) SB3: Subject 3 (DIKU) and 1 person responsible for the video-recording (silent). Setup: Small-talk after the Experiment took place (the following is in Danish): SB3: Det er helt klart, der er nogle ting man ikke tænker på uden at have det og kunne afprøve det. Teacher: Er det nemmere, end hvis I havde skulle sidde og kigge på kode imens? SB3: Nej, det tror jeg kun havde gjort det mere besværligt Teacher: I har jo ikke siddet og kigget specielt meget på det output som programmet har lavet på skærmen. I har siddet og kigget på LEDsne istedet. 130

APPENDIX D. VIDEO TRANSCRIPTIONS D.2. TRANSCRIPTION (IN DANISH) OF SMALL-TALK AFTER TA SB3: Jeg har i hovedet at jeg skal prøve at finde en protokol for dem. Øhm og så prøver jeg at sætte mig i deres sted og der har jeg ikke brug for et kode abstraktionsniveau. SB3: Men det ville nok tjene et ret godt praktisk formål hvis man så rent faktisk prøvede at implementere ens algoritme bagefter. Teacher: Det kunne jo så være næste skridt? SB3: Ja, for nu har man formuleret de her algoritmer for sig SB1: Ja, for nu har vi siddet og leget med det så kunne man godt gå videre med at implementere det. SB3: Ja for så kunne vi prøve at lave det, hvor vi først alokerer hele vejen rundt og så bagefter frigiver og skifter rolle (referer til strategi de benyttede under forsøget). Teacher: Kunne man sige at I bruger de her begreber om at være venlig og være grådig ind i algoritmen? SB3: Men jeg tror også at det kræver at man sådan har snakket om begreberne man bruger i sine algoritmer og prøver at formulere sine algoritmer rigtig meget før man prøver at implementer dem. For ellers tror jeg godt at man kan sidde og være lidt begrebsforvirret eller begrebssvag. Ellers tror jeg ikke at jeg ville vide hvor jeg skulle begynde. Jeg ville nok starte med at tage udgangspunkt i om der skulle være flere roller Teacher: Men du har haft OOPD ikke? Er der har I jo lab-øvelser, men det er meget kode opgaver ikke? Som I har fået med hjem? SB3: Jo Teacher: Hvordan synes du det her er forskelligt fra det? SB3: Jeg synes helt klart at det her er den bedste lab-øvelse jeg har prøvet på DIKU i forhold til at det er meget håndgribeligt. Altså her får man to knapper og to blink. Teacher: Ja og en hjemmeside (griner) SB3: Ja, men den har vi jo ikke engang brugt ret meget. Altså man kan sige at opgaven er lille og afgrænset og det gør den god til en lab-øvelse synes jeg. Det er sværre når man får et stykke papir hvor der står Sådan her lærer du Haskell og sådan her lærer du relationel algebra og her er en fortolker i Haskell, som har 4 bugs, som skal løses først det er egentlig ikke en del af opgaven, men du kan ikke komme videre hvis ikke du gør det og så kan du sætte dig ned for dig selv i 3 timer og prøve at lære det. 131

D.2. TRANSCRIPTION OF SMALL-TALK APPENDIX D. AFTER VIDEOTA TRANSCRIPTIONS (IN DANISH) Det her er jo en helt anden måde at gøre det på. Teacher: Er det individuelle opgaver i OOPD? SB3: Ja, det er det. Undtagen den sidste tror jeg. SB3: Så det her, det er rigtig fedt. Ihvertfald til at starte med, så tror jeg det er rigtig godt at der ikke er mere i det end at man kan sidde og forstille sig hvad man skal til at lave. Altså man kan jo ligesom sige at man kan godt implemente det, på det her plan men det er lidt sværre at vedligeholde de forskellige tilstande i sin kode og sådan noget. Teacher: Tror I, at I vil huske begreberne bedre altså hvis I støder på deadlocks og starvation og tråde igen? SB3: Jammen, helt klart det er meget nemmere at forholde sig til for en. Når man kan se, at man ved at trykke på denne her så lyser den eller lyser ikke. Så kan man også tage stilling til...eller så tror jeg at hvis man skal implemente det, så skal man have en forståelse for at man er denne her (peger på SunSPOTen) Teacher: Du er SunSPOTen? SB3: Ja sådan at man forestiller sig at man har et eller andet program der gentager sig med at det f.eks. Har brug for at tweete hvad skal jeg gøre i denne her situation og sådan ikke? Men, det ved jeg ikke, der tror jeg måske ikke at jeg har de samme forudsætninger som en gymnasieelev for at forestille mig at jeg er på et eller andet punkt i en algoritme. Teacher: Nej, det ved du nok noget omkring algoritmer, som de så ikke gør. SB3: Præcis altså det med at man udfører et program, for det er jo lidt det man gør, når man starter. Når man sætter sig ned og starter med at tænke på et eller andet ikke? Og så snart man har tænkt sig til noget, som måske, måske ikke virker, så prøver man det jo ved at trykke lidt og evaluerer det og ser om det overhovedet fungerer. Det kan godt være at der er et spring der, som jeg ikke ser. Teacher: Hvordan havde I det med at skulle sidde og diskutere imens? Det virkede ikke umiddelbart som det store problem? SB2: Nej, det gjorde det faktisk nemmere jo SB3: Det var lidt svært at komme igang, men når først man er inde i, hvad det er man sidder og laver, altså sidder og diskuterer strategi og sådan, så var det ok. Så er det også ret nemt at arbejde sammen om det det er en fælles platform hvor man 132

APPENDIX D. VIDEO TRANSCRIPTIONS D.2. TRANSCRIPTION (IN DANISH) OF SMALL-TALK AFTER TA hver især kan sidde og tænke ej, men hvad hvis nu... og så får man en ide. Nu skal vi lige prøve at køre min simulering af det her igennem. Så kan de andre ligesom lærer fra personens tankegang ved at se algoritmen bliver udført. Det tror jeg også er ret positivt. Teacher: Har det her undervisning været meget forskelligt fra det undervisning, som I har fået på HTX i programmering? SB2: Ja, det er jo programmeringsundervisning det var meget her er noget kode, det skal I få til at virke, der var ikke rigtig noget algoritme over det. Men jeg tror der er stort forskel på datalogi uddannelsen og programmering der. Ja, det var bare sådan simpel kode ikke? SB1: Ja vi lærer ligesom at implementer det, men vi lærer ikke teorien bag Teacher: Ville man kunne lære java ved at tage sådan en der (peger på en SunSPOT)? Og så få introduktion til java gennem, hvis man lavede tilsvarende øvelser? SB2: Jeg tror det ville være nemmere i hvertfald SB1: Ja, og sjovere SB2: Ja sjovere ihvertfald og mere motiverende SB3: Altså nu har jeg ikke prøve at se hvad man ligesom skulle sidde med for at lave en algoritme til den. Teacher: Det er jo ikke så forskelligt fra det du kender fra Eclipse? SB3: Nej, det er jo det. Altså måske hvis man kombinerede det med at man i forvejen havde roddet lidt med den slags udviklingsmiljøer, så tror jeg at man ville få en rigtig god overgang. Teacher: Men der skulle jo så laves noget introduktion til det SB3: Ja, det skal nok ligge lidt som en forudsætning, at man har prøvet at lege lidt med java og det der grafisk indbygget Teacher: Jeg overvejede faktisk i lang tid, om det skulle drejes over i retning af, at man havde noget introduktion til java som noget det første. Sådan så man havde hele begrebsapparatet omkring hvad er en variabel og hvordan tildeler du en værdi og alle de der ting der hører til, når du skal til at lære at programmere i et nyt sprog. SB3: Ja, det ville i hvertfald hjælpe rigtig meget, sådan så man ikke føler at det er 133

D.2. TRANSCRIPTION OF SMALL-TALK APPENDIX D. AFTER VIDEOTA TRANSCRIPTIONS (IN DANISH) en udfordring at skrive bogstaver i filen. Udfordringen skal ligge i tankerne bag det. Teacher: Men er I så der nu, hvor I kunne have lyst til at tage en af dem med hjem og gå igang med at rodde med dem eller hvad? SB1: Jeg er! (entusiastisk) SB3: Ja, specielt dens andre sensorer, dem synes jeg er meget spændende. Teacher: Så det, der element af, at det er sjovt.. SB1: Det gør det meget bedre SB3: Det gør det helt klart! SB1: Det er jo sjovt at sidde og arbejde med... SB2: (Griber ud efter en SunSPOT og piller ved den) Teacher: Var der nogle ting omkring det jeg sagde, som I syntes var for kedeligt eller det var for tungt i starten? Altså var der for meget snak? Det tog jo lidt tid at komme igang, fordi at jeg var nød til at starte et eller andet sted. Var der nogle ting der, jeg kunne have gjort anerledes? SB2: Du kunne måske have startet med bolden (en af demonstrationerne) Teacher: Altså starte med et eksempel? SB2: Ja, altså bruge bolden som en gulerod, altså sige når I kan det her, kan I også lege med bolden. Teacher: Ja ok jeg forstår godt hvad du mener. SB2: Jeg synes det var fed undervisning. F.eks. At gå ud og sparke til en bold og se hvem der kan sparke hårdest eller få den til at flyve hurtigst altså starte med at vise at det kan lade sig gøre. Teacher: Og så først bagefter vise hvordan det i virkeligheden fungerer SB2: Ja SB3: Ja, det tror jeg også. Altså det der hjælper med det her, er at man virkelig kan se i det her eksempel er hvordan det fungerer at man kan leve sig ind i hele logikken. 134

APPENDIX D. VIDEO TRANSCRIPTIONS D.2. TRANSCRIPTION (IN DANISH) OF SMALL-TALK AFTER TA Teacher: Så i stedet for undervisning, eksempel så istedet sige eksempel, undervisning, eksempel? SB2: Ja, altså så længe at eksemplet er sjovt nok og motiverende nok. SB3: Uhm ja så tror jeg også (tager sedlen med Experiment tekst oplægget) Den er lidt svær hvis man bare får stukket den i hånden, altså at vide præcis hvad det er eksperimentet går ud på. Det gik først op for mig, da jeg læste dining philosophers så tænkte jeg det der billede man har. Men der tror jeg generelt også at det hjælper med de der illustrationer man har i præsentationen. Fordi, det er også det her med at man deler ressourcer. Så snart jeg havde et fysisk billede af det... Teacher: Altså bordet? SB3: Ja, bordet og så en eller anden gaffel eller what ever Teacher: Men det kunne man jo godt lægge ind i altså simpelthen bare sætte billedet ind i eksperiment teksten, så det også var med? SB3: Det var ihvertfald det der lige...altså når først den metafor var på plads, så kunne jeg mappe det direkte ned på spotsne. Men altså, det er en minimal ting, der gik 5 minutter så viste jeg hvad det handlede om. Teacher: Men altså tusind tak fordi I gad at være med. Det var dejligt at I kunne finde tiden til at være med. Det har holdt hårdt at finde nogen, der gad på det her tidspunkt af året hvis I kommer I tanke om noget som I synes, altså ris, ros, ting jeg kunne have gjort anderledes eller bare gode ideer til andre eksperimenter f.eks. Så må I meget gerne skrive mig en mail hvis det er... SB3: Jeg tænkte måske, det der med at den poster det på Twitter, det er sådan en fed hack, men pga. Netværks delays og sådan, så er det måske federe at den poster det interaktivt på skærmen man kan se på. Teacher: Det kunne man også det var bare for at lave noget der var lidt SB3: Klart, det giver lidt geek credits at putte et eller andet mærkeligt på Twitter. Teacher: Det var mest for at appelere til folk SB3: Det tror jeg også virker Teacher: Det havde været væsentligt nemmere at lave det andet. Det kunne man sagtens. 135

D.2. TRANSCRIPTION OF SMALL-TALK APPENDIX D. AFTER VIDEOTA TRANSCRIPTIONS (IN DANISH) SB1: Man kunne måske også prøve at inkludere de der forskellige states som en deadlock kan have. Altså hvordan demonstrerer man det? Teacher: Nå, så du ville have haft at jeg havde taget de der fire kriterier for at en deadlock opstår og sagt hvordan kan vi mappe dem ned på en SunSPOT? SB1: (nikker) SB3: Men jeg syntes altså også det var godt, det der med, at vi havde et tidspunkt, hvor vi var kørt fast i vores strategi vi havde præsenteret min og så sad vi sådan lidt og kiggede på hinanden og så kom du med et forslag om at hvad nu hvis man tænkte i par istedet for. Det tror jeg også var rigtigt altså en nyttig ting. Altså for at få folk til at tænke i nye baner. Altså sådan et enkelt forslag kan starte folk op igen. Teacher: I var jo inde i nogen af de rigtige ting, men nogen gange kan man godt hænge fast hvis man forelsker sig i en strategi ikke? SB3: Ja SB3: (Trykker på SunSPOTen) - tweet! 136