A C4 Toolkit for the Teaching and Learning of Concurrency
Bryan Patten, BA (Mod.)
A dissertation submitted to the University of Dublin,
in fulfilment of the requirements for the degree of
Master of Science in Computer Science
October 2005
Declaration
I declare that the work described in this dissertation is, except where otherwise stated, entirely my own work and has not been submitted as an exercise for a degree at this or any other university.
Signed: ______Bryan Patten, BA (Mod.) October 2005 Permission to lend and/or copy
I agree that Trinity College Library may lend or copy this dissertation upon request.
Signed: ______Bryan Patten, BA (Mod.) October 2005 Acknowledgments
I would like to extend my appreciation to my supervisor, Brendan Tangney, for his advice, patience and guidance throughout the duration of this project.
I would also like to thank everyone in the Centre for Research in IT in Education (CRITE) for their expertise, enthusiasm and humour during my time there.
Finally I would like to thank my family for their support and encouragement throughout my time in college.
Abstract
Computer Science is a non-trivial subject matter. Many topics, such as Programming and Object-Oriented design are complex to teach and learn, due to their abstract nature. One fundamental and particularly challenging area is Concurrency - the managing of a system where many processes are running in parallel. Current approaches to teaching Concurrency introduce the concepts within the context of operating systems or parallel programming in a lecture/tutorial environment. This approach presents the learner with the challenge of understanding a complex context before they can begin to tackle the nuanced concepts of Concurrency. Once over this barrier, learners are still faced with conceptualisation problems and often struggle to internalise issues around synchronisation, scheduling and mutual exclusion. Research would suggest that learners taught in a traditional setting often struggle to apply the concepts of concurrency in new environments. An opportunity for supporting learners is provided by the increased integration of technology into education. In particular, many authors are arguing that the growth of pervasive computing will have a large impact on learning. Cost, adaptability and scalability are among the motivations most often cited for using these devices. This research however leaves a major question unaddressed - from a technical and pedagogical perspective, how should mobile technology be used to support teaching and learning? Following an extensive review of the literature and current applications in mobile learning, this thesis argues that the most technologically appropriate and educationally inspired solutions are built on a combination of Collaborative, Contextual, Constructionist and Constructivist (C4) principles. Building on this argument, this thesis focuses on the appropriate use of handheld technology to support the teaching and learning of Concurrency. Specifically this involved the design, implementation and evaluation of the ‘Concurrency Toolkit’, an educationally appropriate artefact that introduces learners to the primitives of concurrency (semaphores, monitors and message passing) within the context of some of its classic problems. The artefact facilitates learners to collaboratively experiment with the primitives in this environment. Learners can then demonstrate their own understanding of these basic primitives and the nuances of concurrent systems by collaboratively constructing their own multi-processing scenarios. Finally, the toolkit was used in a tutorial setting and reviewed by 13 users. The toolkit was also evaluated using a qualitative approach in a case study paradigm. In this setting the learners were highly motivated through using the tool. They also used the toolkit to produce valuable learning outcomes around some of the move difficult concepts in Computer Science. The findings also show that the learners achieved these educational benefits by using the toolkit to take a C4 approach to the problems faced. Table of Contents
1. Introduction ...... 1
1.1 INTRODUCTION ...... 1 1.2 OBJECTIVES ...... 3 1.3 APPROACH ...... 3 1.4 DESIGN AND IMPLEMENTATION ...... 4 1.5 RESEARCH METHODOLOGY AND EVALUATION ...... 5 1.6 CONCLUSIONS ...... 5 2. Concurrency...... 6
2.1 INTRODUCTION ...... 6 2.2 BACKGROUND ...... 6 2.2.1 The Process...... 7 2.2.2 Mutual Exclusion...... 7 2.2.3 Deadlock...... 8 2.2.4 Starvation...... 8 2.2.5 Fairness...... 9 2.2.6 Concurrency Mechanisms...... 9 2.2.7 Conclusion ...... 18
2.3 TEACHING AND LEARNING CONCURRENCY ...... 19 2.3.1 Context of Concurrency ...... 19 2.3.2 Approaches and Tools ...... 21 2.3.3 Lectures...... 21 2.3.4 Tutorials...... 22 2.3.5 Problem Based Learning...... 23 2.3.6 Software Visualisation...... 27 2.3.7 Temporal Logic ...... 32
2.4 CONCLUSION ...... 32 3. The use of handheld technology in learning ...... 34
3.1 INTRODUCTION ...... 34 3.2 BACKGROUND ...... 35 3.3 CLASSIFICATIONS ...... 36 3.4 FUNCTIONALITY FRAMEWORK ...... 37 3.4.1 Administration ...... 38 3.4.2 Reference ...... 39 3.4.3 Interactive ...... 39 3.4.4 Microworld ...... 41 3.4.5 Data Collection...... 42 3.4.6 Location Aware ...... 45 3.4.7 Collaborative...... 46
3.5 PEDAGOGICAL UNDERPINNING ...... 47 3.6 CONCLUSION ...... 48 4. Design...... 50
4.1 INTRODUCTION ...... 50 4.2 PEDAGOGY GUIDELINES ...... 51 4.2.1 Contextual...... 52 4.2.2 Constructivism and Constructionism ...... 53 4.2.3 Collaboration...... 54 4.2.4 Review...... 55
4.3 DESIGNING THE TOOLKIT ...... 57 4.3.1 Technology Design Decisions ...... 57 4.3.2 Task Design Decisions...... 57 4.3.3 Task Setting Design Decisions...... 58 4.3.4 Task Support Design Decisions ...... 60 4.3.5 Task Evaluation Design Decisions ...... 61
4.4 DESCRIBING THE TOOLKIT ...... 62 4.5 CONCLUSION ...... 63 5. Implementation...... 64
5.1 INTRODUCTION ...... 64 5.2 SELECTING A PLATFORM ...... 65 5.3 TOOLKIT ...... 66 5.4 TASK 1...... 68 5.4.1 Bee ...... 68 5.4.2 Flower...... 69 5.4.3 Exchanges...... 69
5.5 TASK 2...... 70 5.5.1 Bee ...... 70 5.5.2 Flower...... 70 5.5.3 Exchanges...... 70
5.6 TASK 3...... 71 5.6.1 Philosopher...... 71 5.6.2 Fork ...... 72 5.6.3 Exchanges...... 72
5.7 TASK 4...... 73 5.7.1 Customer ...... 73 5.7.2 Barber...... 74 5.7.3 Exchanges...... 75
5.8 TASK 5...... 76 5.9 IMPLEMENTATION ISSUES ...... 76 5.9.1 IR issues...... 77 5.9.2 Interface Issues...... 77
5.10 CONCLUSIONS ...... 77 6. Evaluation & Discussion...... 79
6.1 INTRODUCTION ...... 79 6.2 EXPERIMENT DESCRIPTION ...... 79 6.3 A C4 TOOLKIT ...... 80 6.3.1 Contextual...... 81 6.3.2 Constructivism and Constructionism ...... 84 6.3.3 Collaboration...... 88
6.4 EDUCATIONAL BENEFITS ...... 93 6.4.1 Motivation ...... 93 6.4.2 Learning Outcomes...... 95
6.5 CONCLUSION ...... 98 7. Conclusion ...... 100
7.1 INTRODUCTION ...... 100 7.2 CONCLUSION ...... 100 7.3 RECOMMENDATIONS ...... 101 Appendix A...... 102 Appendix B...... 109 Appendix C ...... 113 References...... 120 1. INTRODUCTION
1.1 Introduction
Computer Science is a difficult subject area to teach and to learn. Filled with topics which are abstract and highly nuanced, its study requires a highly analytical approach. Programming languages, for example, are by definition abstract constructs that are used to solve problems. Not only does the learner need to learn the constructs and syntax for each language, they must also apply them in a logical fashion to solve a wide variety of problems. Given such complex topics, which are difficult to internalise and to communicate, it is not surprising that Computer Science has the highest ‘drop-out’ rate for any subject area in Irish Universities. Concurrency is a particularly challenging subject area. Here learners must manage a system where many processes are running in parallel, often accessing shared resources. This concept is fundamental to how modern computers work. It enables the computer to perform, correctly, numerous tasks at once. A simple example is the ability of the computer to read input from a keyboard, while also presenting that information on the screen. More complex examples include computerized radiation therapy machines, grid computing solutions and enterprise middleware. One author has gone so far as to say “almost any interesting program embodies some aspect of concurrency”(Feldman 1990). For learners however there are numerous challenges. To begin with, the presence of many processes and tasks executing in parallel presents conceptualisation issues, as when the number of processes increase, the number of interactions can grow unmanageably. Learners can also struggle to internalise the basic Concurrency primitives which are used to manage these interactions, such as synchronization, scheduling and interprocess communication. Without a clear understanding of the context, or the fundamental building blocks of concurrency, it is impossible to grasp the workings of a multi-processing environment. Learners require some support to enable conceptualisation of multi-processing environments and to see how the concurrency primitives are used within that context. One opportunity for supporting learners is provided by the increased integration of technology into education. In particular this opportunity is enabled by the rapid growth of mobile technology. Over the past 10 years the use and complexity of
1 mobile devices has increased at an unprecedented rate. The number of worldwide users of mobile phones has passed 1.5 billion 1, while the devices themselves have evolved from portable phones to small, telephonic laptops. This ubiquitous availability has put powerful, personal technology into the hands of users worldwide. Many authors are arguing that this growth of pervasive, ubiquitous, computing will have a large impact on learning. For example, Bull et al claim that it is inevitable that every student will have a portable wireless device (Bull 2002). In the U.S.A. the National Technology Leadership Summit, of the teacher educator associations, claims that “ubiquitous computing will be a widespread force in schools by the end of the decade or sooner” (Bull 2002). Given that change in educational approaches and up take of new technologies in learning are notoriously slow, these statements could be reasonably described as hopeful. They also reflect a certain degree of technological determinism, with the method of delivery – mobile technology – becoming as important as the goal itself - improved learning. However, they also echo the opinion that there are sound reasons to believe that handheld devices will have a role to play in the way we learn (Tinker 1997; Soloway 2001; Roschelle 2003; Naismith 2005). Although cost, adaptability and scalability are among the motivations most often cited for using handhelds it must be remembered that - as in all learning - the use of technology must be driven by pedagogical considerations rather then financial, logistical or technical reasons. A variety of pedagogical approaches have been tried to support learning using mobile devices. These approaches range from instructional content delivery models, to the use of collaborative contextual games. While each approach has its own benefits, this thesis argues that the most educationally appropriate solutions are built on a combination of collaborative, contextual, constructionist and constructivist (C4) principles. These particular educational approaches are well suited to the ubiquitous nature of handheld devices, making use of their continuous availability to learners for learning. This type of continuous availability has been described as bringing a “ready-at-hand” (Heidegger 1962; Soloway 2001; Arnedillo Sánchez 2004) nature to mobile devices. In particular, the “ready at hand” nature allows for technology to be integrated
1 http://www.nokia.ie/nokia/0,8764,29637,00.html
2 unobtrusively within authentic situated tasks. This integration of technology into the learning environment offers numerous opportunities to encourage learners to engage in new ways around the device. Similarly, the inbuilt communication capabilities mean that collaboration between devices can be supported. The combination of appropriate technology within the learning environment and the support for technical and social collaboration mean that mobile devices are well suited for C4 type learning scenarios.
1.2 Objectives
Building on these statements, the objective of this thesis is to explore educationally appropriate uses of handheld technology to support learners in understanding and applying the concepts of concurrency. This is to be done through the development of a mobile artefact that, building on what the research says about appropriate use of mobile technology, supports learners to collaboratively engage in constructing their own understanding of the basic mechanisms of concurrency. Specifically this will involve the development of an artefact to facilitate learners to view, simulate and create multi-processing environments. This artefact would be suitable for learners who are completely new to the area of computer science, and also for those who were at a more advanced stage and wish to apply their understanding of the mechanisms of concurrency in a new context. This artefact will be used in as part of an introductory workshop to Concurrency, enabling learners to play a role in a multi-processing environment. By working together to simulate, control and create a complex multi-processing environment they are supported in understanding the nuances of concurrent concepts and are facilitated to demonstrate their understanding by applying them appropriately.
1.3 Approach
For a number of years, the author has been familiar with the difficulty of teaching and learning concurrency, both as a learner and an educator. With this as a background the author decided to undertake research to investigate the current state of knowledge in teaching concurrency. The author hoped that this information would determine whether there was a need for a new approach to teaching concurrency and highlight valuable approaches currently being employed. Aiming to leverage off the increased integration of handheld technology in education, the author decided to explore
3 whether the use of this technology could be of benefit to the learner. Given the lack of clear classifications in the area, the author decided to undertake an extensive review of the use of mobile technologies to support learning. Specifically this was to involve the development of a functional framework, a classification for handheld applications. Using this framework, the author aimed to identify an appropriate synthesis of sound educational underpinning and appropriate use of technology. This framework was to inform the design and development of a learning tool, to conduct trials on students and evaluate the results of these trials.
1.4 Design and Implementation
The author’s research indicated that while there were a number of tools available for simulating concurrency, particularly those based around the use of formal notation, few existed which allowed the learner to create and manage their own concurrent environments. Specifically, none allowed a number of learners to simulate the actions of processes and resources within a multi-processing environment. To this end the author developed an innovative learning toolkit. The aim of this toolkit was to provide novice and intermediate learners with a scaffolded ‘sandbox’ where they could implement and experiment with the basic mechanisms of concurrency. Specifically, this toolkit would introduce the basic mechanisms of Concurrency including semaphores, monitors and message passing. To support integration into current curricula, the Toolkit would introduce some of these mechanisms within the context of the classic problems of concurrency – in particular the Dining Philosophers and the Sleeping Barber. In practice, the Toolkit is broken down into five separate tasks - the first four tasks highlight a concurrency concept, with the final task is aimed at allowing the learner to demonstrate their own understanding of these concepts. By emphasising appropriate pedagogical practices, the tool aims to facilitate reflection at the two higher ‘skill levels’ by requiring the learner to take responsibility for the proper running of the system. If they mismanage the system, the environment is susceptible to concurrency problems such as deadlock. It is hoped that this will promote metacognition skills in the learner and aid the development of explicit understanding of the role of concurrency mechanisms. The toolkit was developed to work on Microsoft’s .NET Compact Framework. Written in the programming language C#, the toolkit can run on any device which
4 uses Microsoft CE as its operating system, including PDAs and Smartphones. The entire application is standalone, and once downloaded will install automatically on the user’s device. The toolkit is aimed at mobile devices with IR (Infra-Red) capabilities. It uses the IR features to support inter-process communication, such as message passing.
1.5 Research Methodology and Evaluation
The research methodology used in this research can be outlined in the following steps: - The investigation of the current state of knowledge in teaching concurrency, including approaches using simulations. - The investigation of the current use of mobile technology in learning, specifically the appropriate synthesis of technological capability and educational underpinning. - The design and development of a novel artefact enables learners to collaboratively construct their own understanding of the basic mechanisms of concurrency. - The evaluation of the artefact using intermediate and novice computer scientists. The evaluation strategy involved qualitative measures to review the impact of the toolkit on the learner. A case study was carried out, with in-depth qualitative analysis from a number of users. Students completed a survey at the end of the usage period to gather feedback on the perceived value of their experience. The author observed the usage of the tool during each session and recorded these observations. The data from both direct and indirect methods were combined and analysed.
1.6 Conclusions
The conclusions evaluated the results of the research against the stated research aims and objectives. Through this analysis a number of achievements and recommendations are highlighted. The conclusions indicate the primary success of the research in that it was concluded that the artefact did support a C4 approach to learning. It was also concluded that the learners achieved valuable learning outcomes through their use of the toolkit.
5 2. CONCURRENCY
2.1 Introduction
“Concurrency – A running together in place or time” This chapter provides a background to the issues of Concurrency, specifically the issues which learners must face to gain a basic understanding of the domain. These issues, the problems and mechanisms of Concurrency, are fundamental to the correct running of many complex systems. Having introduced these concepts, the standard approaches to the teaching and learning of these problems and mechanisms are then reviewed. This analysis of the current state of knowledge is aimed at highlighting whether a new approach to teaching Concurrency is necessary.
2.2 Background
A computer is required to do several things at the same time. While receiving input from a keyboard, it is often outputting text to a screen and reading from a disk. More complex examples can be found in critical systems, from computerized radiation therapy machines to Enterprise Middleware solutions. The ability to run numerous tasks simultaneously, and correctly, is fundamental to modern computer systems. A comprehensive understanding of computer science requires an understanding of how a machines manage running multiple concurrent tasks. The goal of this domain is to allow systems to run numerous processes simultaneously and correctly. Specifically the goal is to develop systems that allow processes to maintain two fundamental properties – Safety and Liveness. These properties are regularly described in the literature (Andrews 1991; Bacon 1998; Magee 2000) as follows: A safety property asserts that nothing bad happens during execution. A liveness property asserts that something good will eventually happen. These properties are broad and can clearly be applied to numerous ways. Their implementation raises a number of well known issues, specifically: Mutual Exclusion, Starvation, Deadlock and Fairness. To ensure the two fundamental properties and deal with any issues which can arise, system designers can employ a number of basic mechanisms, such as: Message Passing, Semaphores and Monitors.
6 Within Computer Science, the broad concept of managing concurrent tasks falls under the heading of ‘Concurrent Systems’. This heading is purposely vague, as concurrency is a cross cutting issue relevant to Operating Systems, Distributed Systems and Programming Languages, to name but a few. There are two traditional approaches of introducing the abstract problems and solutions, through the use of processes and Operating Systems or threads and an appropriate Programming Language (such as Java). This thesis will follow the ACM/IEEE (IEEE. 2001) curriculum guidelines and the majority of the literature by referring to the issues which follow in the context of processes and Operating Systems. The approach this chapter will follow is to introduce the concept of processes and then discuss the issues and mechanisms of concurrency within that context.
2.2.1 The Process One way of viewing a computer system is as a series of runnable software, referred to as ‘processes’. A process can be defined as “any executing program, including the current values of the program counter, registers and variables.” (Tanenbaum 1997) At its simplest, a process is an activity of some kind or an instruction that makes the CPU ‘do’ something. These processes are described as being in one of three states: i) Running (the process is currently active) ii) Ready (the process is temporarily stopped and is ready to run) iii) Blocked (the process is waiting for an external event before it can run) The role of concurrent systems is to ensure that when there are a number of processes running concurrently, that they all maintain the fundamental properties of safety and liveness.
2.2.2 Mutual Exclusion Without structure, these processes can act in a way detrimental to themselves and each other. For example, if two processes are running concurrently and using the same memory to store critical information, it would be possible for one process to delete the information belonging to the other. This problem causes ‘race conditions’ – where the final result of a process can be altered by the timing of other processes. This can be exceptionally difficult to debug, as a process will run correctly most of the time, but once in a while something unusual will happen without apparent explanation. This behaviour breaks the safety property described earlier.
7 To solve this problem, processes must identify ‘critical sections’ where they use a shared resource (in OS terms, most commonly memory). By identifying these sections and insuring that no two processes are ever in the same critical area at the same time it is possible to avoid race conditions. This concept is known as mutual exclusion. A formal way of describing this issue would be to say that Mutual Exclusion is a safety property which asserts that two processes may not interleave certain sequences of instructions. While the order of process completion is not important, one sequence of instructions must be completed before the other starts. (Ben-Ari 1990)
2.2.3 Deadlock Another important safety issue is the absence of deadlock. Deadlock, a state where no process can perform an eligible action, is one of the most common issues to occur in Concurrent Systems. Systems must insure that no sequence can exist where a group of two or more processes are unable to proceed, due to each process monopolizing access to resources, while waiting for the release of resources held by others in the group. With each process ‘blocked’ waiting for a resource held by another, no process can exit its condition. Formally there are four conditions have been identified (Coffman 1971) which, when all are true, signify deadlock: Mutual Exclusion – The processes make use of serially reusable resources Wait for – The processes hold resources allocated to them while they wait for additional resources No pre-emption – A process cannot have their held resources forcibly removed from them. Circular wait – A cycle of processes exists such that each process holds at least one resource that is being requested by the next process in the cycle.
2.2.4 Starvation A liveness issue strongly associated with Deadlock is the absence of Starvation. In general terms Starvation, often described as a ‘near Deadlock’ state, is a situation when an individual process can never perform a specific action, such as gain access to a resource. In this example the liveness issue is that the process will never get access to the resource, the ‘something good’ will never happen.
8 2.2.5 Fairness The other major liveness issue is one of Fairness, which is concerned with ensuring that a process will eventually get the chance to proceed regardless of how other processes behave. Ben-Ari (Ben-Ari 1990) describes four possible specifications of fairness: Weak Fairness: If a process continuously makes a request, eventually it will be granted. Strong Fairness: If a process makes a request infinitely often, eventually it will be granted Linear Waiting: If a process makes a request, it will be granted before any other process is granted the request more than once. FIFO (first-in, first-out): If a process makes a request, it will be granted before that of any process making a later request. These various approaches are fundamental to Concurrency, as they define how efficient a system is likely to be. For example, if it is important to deal with one specific process first – then implementing a FIFO approach to fairness would prevent the desired running of the system. Choosing the appropriate approach to fairness is one of the more nuanced elements of Concurrency.
2.2.6 Concurrency Mechanisms To guarantee that a system can run numerous processes simultaneously and correctly, system designers must ensure the properties of safety and liveness. To enable this, a number of concurrency mechanisms have been developed, which – when used correctly – can insure mutual exclusion and fairness, while preventing issues such as deadlock and starvation. There are three major mechanisms – semaphores, monitors and message passing. System designers must be able to understand the issues of concurrency that they face, and deploy the appropriate currency mechanism to deal with the problem. Each approach has positive and negative aspects, each of which is examined in turn below.
2.2.6.1 Semaphore The term semaphore is a compound of two Greek roots. The first half is sema-, from sema (sign), while the second half -phore, is a suffix that generally relates to carrying or bearing and comes from the Greek verb pherein (to carry/bear). So a literal
9 translation would be ‘bearing a sign’. The concept of Semaphore communication was developed in France in the late 18 th Century and was used extensively by Napoleon’s armies. By positioning a series of angled rods or flags, information is relayed between locations. Semaphore techniques became prominent in shipping, and are still used by ships when communicating in an emergency. This concept of using a visible resource (a flag or rod in Napoleon’s time) for communicating was adapted to the process model, where a shared variable is ‘visible’ to all relevant processes. By referencing against this shared variable, normally an integer, processes can check whether a critical area is being accessed. Specifically Semaphores have exactly two operations, Wait and Signal. Ben-Ari (Ben-Ari 1990) defines these two operations as follows:
Wait(S) If S>0 then S := S-1 else suspend the execution of this process.
Signal(S) If there are processes that have been suspended on this semaphore, wake one of them else S := S+1.
Taking inspiration from history, an abstract example of the use of a semaphore to ensure mutual exclusion could be described as follows: There are two farmers, who share a field. Due to some family dispute, the farmers can’t stand the sight of each other and want to ensure that they are never in the field at the same time. To support this condition, the farmers place a flag at the entrance to the field. If the flag is raised, this means that a farmer is in the field, if it is lowered this means that no one is in the field. When a farmer (the process) wishes to enter the field (the resource/critical section), they check the state of the flag (the semaphore), and act as follows: The flag is lowered – they raise the flag, and enter the field. When finished, they leave the field and lower the flag. The flag is raised – they wait near the gate, waiting for the flag to be lowered. When it is, they go the gate and act appropriately. Ben-Ari (Ben-Ari 1990) describes the same process in pseudocode, with each farmer being represented by a process ‘P1’ and ‘P2’, the actions each farmer performed within the field being described as ‘Critical_Section_1’ and ‘Critical_Section_2’ and finally the flag being described as the semaphore ‘S’. S responds to the two
10 operations, Wait(S) and Signal(S), as previously described. Code Fragment 1: Semaphore
S: Semaphore := 1;
task body P1 is
begin
loop
Non_Critical_Section_1;
Wait(S);
Critical_Section_1;
Signal(S);
end loop;
end P1;
task body P2 is
begin
loop
Non_Critical_Section_2;
Wait(S);
Critical_Section_2;
Signal(S);
end loop;
end P2;
Though relatively simple, this mechanism represents a classic method for restricting access to a shared resource, and is the primitive synchronization mechanism associated with many operating systems. As a mechanism however, it has a number of deficiencies. For example, returning to our abstract description, if a farmer ‘dies’ while in the field, the flag will remain raised for eternity – stopping anyone ever getting access to the field again. Similarly, if a farmer ‘forgets’ to lower the flag on leaving the field each farmer will presume the other is in the field and the field will lie fallow for ever. Practically, it is possible – if incorrectly implemented - for a process to ‘die’ while in the critical section, or to ‘forget’ to reset the semaphore on exiting the critical section. In these cases the semaphore will continually block any process wishing to enter the critical area.
11 Another issue is one of ‘Busy-Waiting’, also known as a spin-lock. Continuing with the abstract example, it would be possible that farmer A, having checked the flag and found that farmer B is in the field, will go home for a cup of tea. After a certain amount of time – say 15 minutes – farmer A will return to check if farmer B is finished. Finding again the flag raised, farmer A will repeat his cycle and go home once more. However within each 15 minutes, farmer B will have taken a break and gone back to work in the field, ensuring that farmer A never gets access. This lack of fairness in the system insures that one farmer is in effect starved of access to the field and in a deadlocked state. On a practical level, a process, while suffering starvation, would also waste valuable processing power continually checking a semaphore value. To avoid busy-waiting, a semaphore can have a queue associated with it. Now if farmer A finds the flag raised, he will write his name on a sheet beside the gate. If farmer B wants to re-enter the field after leaving he must add his name to the list and wait till farmer A is finished. Again, on a practical level this means that if a process finds the semaphore set to 1, it will be put into the semaphore’s queue. When the semaphore is released it will notify a process in the queue, normally in FIFO fashion. This solution still depends on each semaphore being correctly managed by each process - if one of the processes forgets to call Signal(S) after a critical section, the program can still deadlock.
2.2.6.2 Monitors A more complex concurrency mechanism is the monitor. The monitor can be used, like a semaphore, to achieve the properties of safety and liveness. It differs from a semaphore in that it is structured; the responsibility of isolating the critical section is focused on a few modules and not distributed throughout the system. The monitor concept was developed by Tony Hoare, who also developed the QuickSort algorithm. Monitors can be regarded as a generalization of the kernel found in operating systems. Critical sections are centralized in a program, the monitor, with processes requesting the program to perform specified ‘services’ on the critical sections. By focusing all access to critical sections through a monitor, mutual exclusion can be guaranteed. If a monitor receives a number of service requests simultaneously, it ensures that the requests are processed in sequence. This approach is based around the concept of ‘encapsulating’ data and operations into a single program or module.
12 The specific attributes of a monitor can be broken down to: A set of procedures that allow interaction with the shared resource A mutual exclusion lock The critical variables associated with the resource A monitor invariant (test variable) that defines the assumptions needed to avoid race conditions However, associated with these additional properties, is the fact that monitors require more computational power then semaphores. To describe the role of a monitor more abstractly, let’s return to the field and our two farmers. Due to their rising dislike for each other, the farmers want to ensure that they don’t ever share the same field. To this end, they employ a helper to stand by the gate. In some monitors, the helper is trained to do a specified number of appropriate tasks - ploughing the field, planting seeds etc. When a farmer wants a specific task done, they contact the helper and place their request. The helper keeps a log of these requests, and can deal with them in an appropriate way – by order of priority, by time requested and so on. It is up to the helper to ensure that the safety and liveness properties are always met. Even in this abstract example, you can still see that a helper is a more ‘expensive’ form of infrastructure than a flag – replicating the fact that a monitor requires more computational power. Again, a more formal description of this example can be found in the pseudocode of Ben-Ari (Ben-Ari 1990). Again, the farmers are represented by ‘P1’ and ‘P2’. The actions each farmer wishes performed is described as ‘Critical_Section_1’ and ‘Critical_Section_2’. Finally, the helper is described as the monitor ‘M' Code Fragment 2: Monitor monitor M is
B: array(0..N-1) of Integer;
In_Ptr, Out_Ptr: Integer : = 0;
Count: Integer := 0;
Not_Full, Not_Empty: Condition;
procedure Critical_Section_1(I: in Integer) is begin
if Count = N then Wait(Not_Full); end if;
13 B(In_Ptr) := I;
In_Ptr := (In_Ptr +1) mod N;
Signal (Non_Empty); end Critical_Section_1;
procedure Critical_Section_2(I: out Integer) is begin
if Count = 0 then Wait(Not_Empty); end if;
I := B(Out_Ptr);
Out_Ptr := (Out_Ptr +1) mod N;
Signal(Not_Full); end Critical_Section_2; end M;
task body P1 is
I: Integer; begin
loop
Non_Critical_Section_1;
Critical_Section_1(I);
end loop; end P1;
task body P2 is
I: Integer; begin
loop
Non_Critical_Section_2;
Critical_Section_2(I);
end loop; end P2;
Clearly, this approach can be complex to implement. It does provide numerous benefits however. By centralizing the ‘actions’ with the monitor, we can guarantee
14 the properties of safety and liveness. Also, the inherent ‘information hiding’ has benefits from a system design perspective – providing the designers with greater flexibility to modify the functionality of system. If a system needs to be updated to perform new tasks, due to user requirements, it is easier to alter the centralised tasks of the monitor than attempting to alter the global tasks of the various users. Returning to our abstract example, it would be easier to retrain our helper in new tasks – using new machinery for example – than having to retrain both the farmers. This approach is often associated with the programming language facility of encapsulation. The monitor approach does have some drawbacks. One argument is that it is simply a ‘synchronization’ mechanism and does not allow true concurrency. Abstractly concurrency has been defined as “a running together in time and place”. The monitor actually insures that each task is done serially – at no stage are two actions being performed at the same time. A far more practical issue arises around the implementation of nested monitors - a monitor in a monitor. Here, the issue of deadlock can occur. This shifts the responsibility for ‘valid’ systems back to the designer - a complex task and leads to difficulty in validating the ‘correctness’ of the system. Despite these issues, monitors are a fundamental building block of concurrent system. The Monitor concept is an integral part of the Java programming language. The .NET framework, in which the ‘Concurrency Toolkit’ is written, does not support Monitors, though it is possible to implement a monitor in C# manually.
2.2.6.3 Message Passing The implementation of semaphores and monitors relies on the use of shared variables to represent the state of different processes and to insure correct behaviour across the system. An alternative approach to maintaining stability and correct behaviour of safety and liveness is to have the processes communicate between each other, using send and receive messages. This approach enables systems to interact and collaborate when they don’t have access to shared memory or variables, particularly when based on different machines, and is a common approach used by Operating Systems and Distributed Systems. It is the basis of an area known as Inter-Process Communication (IPC). The forms of message passing can be broken down into two models – synchronous,
15 where the sender waits until he is sure that the message has been received, and asynchronous, where the sender assumes the message has been received. Synchronous Message Passing While it is possible to ‘multicast’ these messages, the simplest approach to regard is one of one-to-one communication. Here one process, the Sender, transmits a message to a second process, the Receiver, over a communication mechanism, the channel.
Sender Channel c Receiver
v = receive( radio ) send( e,c )
Figure 1: Synchronous Communication Kramer and Magee (Magee 2000) describe the operations as follows: send( e,c ) Send the value of the expression e to channel c. The process calling the send operation is blocked until the message is received from the channel. v = receive( c) Receive a value into local variable v from channel c. The calling process is blocked waiting until a message is sent to the channel.
The first process, whether a sender or receiver, to perform a ‘channel operation’ is blocked until its partner performs the appropriate complementary action. After a communication has occurred, sender and receiver can proceed independently. So, if the sender performs the send action it must wait until it receives confirmation from the receiver before it can proceed. Abstractly, let us return to our farmers and their field once more. Using the synchronous message passing approach to ensure mutual exclusion would require the farmers to start talking with each other – so let us imagine each farmer has a two-way radio. When wishing to enter the field, farmer A will send a message saying that he is entering the field. Farmer A can not proceed and enter the field until he is sure that farmer B has received his message. This process could be graphically described as follows:
Sender Channel radio Receiver 16 send(“Going to Field” ,radio )
v = receive( radio )
Figure 2: Synchronous Example There are a number of issues with this approach, incorrectly implemented it is susceptible to delay and deadlock. For example, given that it is possible for processes to die, it is possible that a process will be waiting eternally for a response from a process which no longer exists. It is also possible for a process to be busy when receiving a message – and taking a substantial period of time to acknowledge that it has received a message. This delay could be unnecessarily denying another process to a valuable resource. Asynchronous Message Passing Asynchronous message passing addresses many of the issues raised by synchronous message passing. This approach is common when we have many-to-one communication scheme – as in there are many senders and one receiver. For consistency, this we will deal with the situation in a one-to-one situation. Again one process, the Sender, transmits a message to a second process, the Receiver, over a communication mechanism, a channel. There is also the addition of a message queue associated with the receiver.
Sender Receiver Channel c
send( e,p ) v=receive( p)
Figure 3: Asynchronous Communication (Magee 2000) Kramer and Magee (Magee 2000) describe the operations as follows: send( e,p ) send the value of the expression e to port p. The process calling the send operation is not blocked. The message e is queued at the port if the receiver is not waiting.
v = receive( p) receive a value into local variable v from channel p. The calling process is blocked if there are no messages queued to the port.
17 The sending process performs its action and sends the message to the receiver. Having done this, it proceeds independently. The message is either given directly to the receiver or, if the receiver is not ready to receive, added to the message queue. Periodically, the receiver will check the message queue for new messages, and retrieve messages normally in a FIFO fashion. If there are no messages in the queue, the receiver will wait until one is received. Let us return one last time to our farmers and their field. Using an asynchronous message passing approach to ensure mutual exclusion our farmers move to communicating via email. When wishing to enter the field, farmer A will send a message saying that he is entering the field. Farmer A presumes that farmer B has received the message and enters the field. Farmer B checks his email every few minutes, and eventually sees that the field will soon be in use. This process could be graphically described as follows:
Farmer A Farmer B send( “I’m entering v=receive the field”, ([email protected] )
[email protected] ) Figure 4: Asynchronous Example This approach removes the potential for unnecessary delay or deadlock, as at no stage is one process dependant on a response from another. Unfortunately it does raise other issues. For one, the proposed implementation is built upon an ideal system – a system without the potential of message loss, or corruption in the channel. Without acknowledgement, there is no way to guarantee that the message has been received. Also, as the sender proceeds without receiving an acknowledgement, there is a danger that some safety properties could be compromised by the sender’s assumption that the message has been received.
2.2.7 Conclusion Concurrency represents the domain of enabling systems to run numerous processes simultaneously and correctly. In particular, this means that a system can guarantee two fundamental properties – Safety and Liveness. A system with numerous processes running simultaneously is susceptible to a number of issues, the most notable being – mutual exclusion, deadlock, starvation and fairness. To combat these issues, system designers have developed a number of tools specifically – semaphores
18 and monitors. The appropriate use of message passing can also help ensure safety and liveness properties. The task for system designers is to identify the issues their system is likely to face, and deploy the mechanisms of concurrency appropriately to ensure that these pitfalls are avoided.
2.3 Teaching and Learning Concurrency
While personal experience and anecdotal evidence suggested that teaching and learning concurrency is problematic, a review of the relevant literature showed that it is a widely accepted issue. (Feldman 1990; Traxler 1994). Common issues facing learners include: - Conceptualising processes occurring simultaneously - Moving away from procedural paradigm issues - Internalising the role of concurrent mechanisms - Applying the mechanisms appropriately in new environments In particular, the issue of conceptualising a multi-processing environment seems to offer real challenges to the learner. Without an overview it is difficult to comprehend how mechanisms can be appropriately applied, leading to difficulties for learners in applying the concepts appropriately. These issues were identified throughout the literature, with the following comment from a final-year undergraduate student in Computer Science (Traxler 1994) being particularly prescient: “The main problem in trying to learn the concurrent paradigm is trying to imagine processes occurring simultaneously… It is very difficult to keep track of all the actions taking place in a concurrent process.”
2.3.1 Context of Concurrency Concurrency is usually introduced as a subsection of an Operating Systems course. This is for historical reasons, as OS were the first major domain within Computer Science which faced concurrency issues. As early as 1978 the ACM curriculum identified Process Management as a subtopic of the OS module. The suggested topics to be covered included: Asynchronous processes. Semaphores. Ready lists. Implementing a simple scheduler.
19 Examples of process control problems such as deadlock, producer/consumers, readers/writers. The complexity of the OS domain can present an additional barrier to learners, with Traxler describing it as sad that much of the literature “contains ad hoc elements of operating system theory and hardware constraints that make it difficult for a beginner to understand” (Traxler 1994). Learners must be comfortable in the OS domain, understanding the basic mechanisms of OS before they can deal with the abstract concepts of concurrency. Due to the complexity of the OS domain, the module is normally introduced towards the end of an undergraduate computer science degree. This is reflected in the current ACM/IEEE Computer Curriculum (IEEE. 2001), which suggests that “Concurrent and Distributed Systems” should be thought at the ‘advanced’ stage. The recent growth in concurrent systems offers opportunities to introduce learners to concurrency in a different context. Concurrency can be explored in the context of distributed system topics such as Grid Computing and Enterprise Middleware or programming languages like Java or SR (Andrews 1993). By placing the concepts in a new context, learners are given a new perspective on their usage. However, these approaches present similar challenges, as the learner must understand the mechanisms of distributed systems or programming before being able to understand the abstract concepts of concurrency. Kurtz for example felt, with regard to the SR language, that “the language has a steep learning curve and the course became too focused on learning a particular programming language rather than learning about parallel computing.” (Kurtz 1998). Another approach is to introduce the learners to the abstract concepts of concurrency away from the context of Operating Systems, Distributed Systems or Programming Languages. By reducing the technical element of the context, and placing it in a real life setting, learners should have less difficulty in conceptualising the environment, mechanisms and interactions. This approach can be seen in the positioning of the ‘classic problems’ of concurrency, for example - the Dining Philosophers and the Sleeping Barber. These ‘classic problems’ are mentioned throughout the literature, and are usually accompanied with solutions to exemplify the different mechanisms or attributes of concurrency. While this approach is beneficial to the learner, Downey found that “most students were able to understand the solutions to these problems, but
20 few would have been able to produce them, or solve similar problems.” (Downey 2005)
2.3.2 Approaches and Tools A number of approaches have been adopted for teaching concurrency; in general they fall into the following categories: - Lectures - Tutorials - Problem Based Learning - Software Visualisation - Problem Based Animations - Finite State Machine Visualisation - Temporal Logic There is very little empirical evidence to evaluate the impact of these approaches, but the focus of recent research has been towards software visualization and away from solely a lecturing environment.
2.3.3 Lectures The standard approach to teaching Computer Science in general and Concurrency in particular has been through a combination of lectures and tutorials. A lecturer will introduce a topic to a large group of students, with the support of their own notes or a text reference. This approach has been a common form of instruction since the 12 th century, when lecture notes of respected thinkers reached a wide circulation. Little has changed in the paradigm since then, with the lecturer and student engaging in a transmission model of communication, with the lecturer instructing by transmitting facts to a passive recipient, the student. This form of didactic instruction is common across universities and is regarded as well suited to reinforcing ideas, and providing an introduction to a topic. Lectures do however present difficulties for facilitating high-level cognitive objectives, such as analysis (Gage 1992). These high-level skills are required to facilitate learners moving past information acquisition and moving towards the ability to apply concepts in new scenarios appropriately. Also, given the large number of students, it is difficult to enable teacher-student interaction (Gage 1992), which has a
21 negative effect on long-term retention. Magnesen’s table (Linder 2001) suggests that the average retention of material that learners solely hear is 20%. This figure increases to 70% when it is discussed. Given this combination of lack of support for high-level cognitive functions and lack of support for long-term retention, it is clear that a lecture in isolation isn’t a suitable environment for gaining an in-depth understanding of a complex and important topic such as concurrency.
2.3.4 Tutorials Many universities supplement lectures with tutorials, which are classes of a small number of students supervised by a Teaching Assistant, a ‘TA’, though perhaps the term ‘tutor’ might be more appropriate. The role of the TA is to guide a discussion between the students on the materials introduced during the lecture or to guide the students through some relevant course work. In the case of learning concurrency, many text books support the latter approach. This course work presents the issues of concurrency within the context of the approach of the text. For example, Ben-Ari’s ‘Principles of Concurrent and Distributed Programming’(Ben-Ari 1990), which introduces concurrency within the context of the programming language Ada, provides a series of exercises for experimenting with examples that have been written in Ada. This approach is difficult for texts which are based solely around OS, as they are by their nature large, complex pieces of software which are expensive to model. To circumvent this issue, the literature presents concurrency in OS through mathematical models, often a form of temporal logic. In a tutorial the students must experiment with this model to handle a variety of inputs which simulate common concurrent issues. Tutorials can prove beneficial to learners. By design they are more suited to a constructivist learning paradigm; the responsibility for learning is with the student, with the ‘TA’ available for guidance. This approach can be a good counterpoint to the didactic lectures, with the potential for students engaging in “the active, constructive of the knowledge acquisition process wherein the learner is not a passive recipient of information but an active and constructive interpreter of meanings.” (Vosniadou 1994) Also, the smaller numbers provide easier access to colleagues and greater opportunities for collaboration. There are issues however with the tutorial approach. A constructivist learning environment is not easily created, requiring skilled facilitation on the part of the TA.
22 Unfortunately, TA’s are often postgraduate students with little experience in facilitating learning and little support from the institutions as regards educational approaches. Also, as previously mentioned, the ‘barriers to learning’ are quite high – the learner must be well versed in mathematics or a specific programming language. Anecdotal evidence and personal experience would suggest that many of these tutorials are more focused on developing an understanding of the equation or programming language than on comprehending the nuances of concurrency. Problems are also rarely expressed within a relevant context for learners, with the topic remaining highly abstract. Finally, as the problems which the students face are predefined and content driven, little scope is available for tailoring the problems to the specific needs of the student. Given the ubiquitous nature of the lecture and tutorial for a number of centuries, there is little reason to believe that they will become less important in education. However, many educational institutions are integrating new approaches to learning into their practice, and there is some research into alternate approaches to engaging students.
2.3.5 Problem Based Learning One standard way to enhancing the learning experience of students is to take a problem based approach. Here ‘problems’ are placed at the centre of the paradigm, with all learning being driven by the problems rather than the content of the subject area. Engel identifies two separate (Engel 1991) purposes for this approach: i) It is an effective approach for adult learning, given its cumulative approach with the student’s experience becoming progressively more challenging and that it is clearly focused on learning for understanding, with appropriate opportunities provided for reflection. ii) By assisting students towards achieving a specific set of objectives, they will become capable in a set of competences that will be important throughout their professional lives. These competences include many high-level cognitive objectives, including critical and creative thinking, adapting to change etc. In other words, by presenting appropriate contextual zed problem based situations, learners are given the opportunity to achieve higher levels of comprehension by conducting their own independent analysis and investigation of the situation. These opportunities for constructing their own solutions to the problems they are faced with
23 are well suited to what Bruner describes as constructivist learning (Bruner 1966). By providing active and engaging learning opportunities, learners are able to construct new ideas and concepts based upon their current knowledge. Learners use their own cognitive structure (i.e. mental models, schema) to develop their own hypotheses. These problem based situations can be presented to both an individual and group. In a group setting the learner also has the opportunity to gain the benefits of collaboration – by articulating their own understanding of the problem or proposed solution, learners are required to reflect on their own knowledge, which leads to a better understanding of their own thinking process. (Brown 1989) This approach is well-suited to a highly abstract and complex topic such as concurrency, and has been highly prominent in the subject area for over 50 years. Edsger Dijkstra, the renowned Dutch computer scientist, is particularly associated with this approach due to his paper “Cooperating Sequential Processes” (Dijkstra 1965). Here he presented the issue of deadlock within concurrent systems within the context of a dining quintuple eating spaghetti. This was later renamed “The Dining Philosophers” by Tony Hoare. This prompted a number of other well known issues to be placed within a less technical context, including ‘the Sleeping Barber’. These ‘classic problems’ of concurrency, which are prominent throughout the literature and are regularly mentioned in concurrency textbooks, are described in detail below.
2.3.5.1 The Dining Philosophers As previously identified, the issue of deadlock is common in developing concurrent systems. To describe this issue Dijkstra used the example of four individuals who sit around a circular table and spend their lives alternately thinking and eating – Hoare, later described them as the Dining Philosophers – to represent a classic problem of multi-process synchronization. In the world described by the problem, before each Philosopher is a plate of spaghetti, with a fork on either side (i.e. five philosophers, five plates, and five forks). To eat, a philosopher must obtain the forks to his right and left. 2 Problems occur when every philosopher picks up, for example, their right fork. Now the philosophers are in a
2 Another way of imagining this problem is with Chinese food and chopsticks – for the philosophers to eat, they must pick up the chopsticks to their left and right.
24 classical circular-wait deadlock. As described previously, a cycle is now created where each Philosopher (a process) holds at least one fork (the resource) that is being requested by their neighbour (the next process in the cycle). Within this model world of Dining Philosophers, the issue of starvation (Dijkstra intended the pun) is also an issue. Through the ‘hunger’, or inherent selfishness, of neighbouring philosophers, it is possible for one philosopher to be constantly denied access to obtaining both forks. The lack of available forks is an obvious analogy to the scarcity of resources in real computer systems. To ensure the properties of safety and liveness – guarding against deadlock and starvation – requires the diners to co-operate. There are numerous solutions, with Ben-Ari describing the three most common: Asynchronous – One Philosopher agrees to act out of sequence – for example picking up his left fork first. By breaking the cycle of actions – picking up the right fork – safety and liveness can be guaranteed. Semaphores – Though difficult, it is possible to guarantee safety and liveness by making appropriate use of a semaphore on each fork and a global semaphore around the table. Monitors – A more elegant solution can be found by implementing a monitor. The monitor is able to test the value of two fork semaphores simultaneously – getting a global perspective that is not easily achieved using semaphores. By implementing a monitor, you can ensure that a Philosopher will not pick up a fork until he is sure that both forks are free. By experimenting with this problem, learners are given a non-technical introduction to the technical challenges of multi-process synchronization.
2.3.5.2 The Sleeping Barber The challenge of synchronization is ever-present in concurrency. As previously mentioned another common liveness issue is one of fairness, particularly in monitor- based systems. Here the choices a monitor makes around the order in which they deal with processes is fundamental to the fairness of a system. Should a monitor deal with processes on a first come, first served basis? How much attention should be given to a process if it is of a high priority? What about processes which don’t require access to the resource for a long time? These decisions also impact on the efficiency of a
25 system. To illustrate this issue, Dijkstra described the world of the sleeping barber. This world is based around the life of an individual barber (the monitor), who works (the resource) when there are customers (processes) and rests when there are none. Customers entering the barber’s shop will find the barber either sleeping in his chair or working. If he is sleeping, the customer wakes the barber. If he is cutting someone else’s hair, the customer sits down in one of the finite chairs available (the queue). If there are no seats available (the queue is full), the customer leaves and must return at a quieter time. The benefit of this problem, is that it poses two challenges – one of safety and one of liveness. If the barber and customers don’t coordinate their activities correctly – issues of deadlock will occur. Similarly, if the barber doesn’t take a ‘fair’ approach to dealing with a queue that has developed, customers will suffer from starvation. From a deadlock perspective, the challenge is described as a classic double rendezvous problem. Rendezvous is a message-passing protocol, similar to synchronous message passing, in which a process (the customer) is suspended in a queue until the monitor (the barber) performs a requested action (cutting the customer’s hair). The standard approach to solving this problem is to deploy three semaphores: one for the queue, one for the barber (to describe his state) and one for mutual exclusion. Incorrectly implemented, this solution can lead to safety issues – for example, it would be possible for the barber to be waiting for a customer, while the customer is waiting on the barber – resulting in deadlock. From a liveness perspective the issue is one of fairness. In particular – which fairness specification the monitor takes. As previously mentioned, Ben-Ari described four specifications – weak, strong, linear and FIFO; a challenge facing designers is to implement these abstract specifications appropriately for their specific problem. Choosing the incorrect specification will mean that certain processes are likely to starve. Specifically, in the Sleeping Barber problem, the approach the barber chooses in dealing with the queue could lead to a customer waiting forever for their haircut. This problem description involves only one barber, there is reference in the literature to the multiple sleeping barbers problem (Stallings 2000), which is similar in the nature of implementation and pitfalls, but has the additional complexity of coordinating several barbers among the waiting customers.
26 2.3.5.3 Conclusion In its theoretical implementation, the problem based approach has numerous benefits. By engaging learners in independent investigation solving and constructing their own understanding of contextual zed problem, higher levels of comprehension can be achieved (Bruner 1966). Problems can also be set for groups, bringing the associated benefits of collaborative learning, including reflection (Brown 1989). Unfortunately, the practical implementation of these scenarios for teaching concurrency tends to stray from these theoretical goals. In reality, they are used as illustrative examples of issues that can arise – such as deadlock, fairness and the likes. The problems are often used to support an instructional approach to learning, with the solutions generally accompanying the question – removing the motivation for the learner to construct their own understanding of the issues. While discussing these problems Downey commented that he felt “most students were able to understand the solutions to these problems, but few would have been able to produce them, or solve similar problems.” (Downey 2005). The most educationally constructive use of problem based learning is currently found in the use of programming problems. Here, problems are presented in the context of a particular programming language and learners must develop their own appropriate solutions. By building their own solutions to problems, learners must demonstrate an understanding of the wider topics through the practical implementation of a solution which uses the basic mechanisms of concurrency. The difficulty with this approach is that it assumes previous technical ability on the part of the learner, an unreasonable assumption given the problems associated with the teaching and learning of programming (Riley 1981; Henderson 1986). Jenkins goes as far to state, “The graduating student who professes a complete inability to write a simple program is commonplace” (Jenkins 2001). Clearly, by presenting the issues of concurrency through the lens of programming will create a significant barrier to learning for a wide number of students.
2.3.6 Software Visualisation Given that innovations in computer graphics have enabled huge advances in the domain of animation, it is perhaps unsurprising that these advances have been applied to the concepts of Computer Science. The idea of creating visual representations of computer systems, or the algorithms that underlie them, has been popular for some
27 time. There have been numerous categorisations (Price 1993; Roman 1993) and implementations that create visual representations of networks and programs. From the perspective of concurrency, these representations have focused on two specific styles of implementations - Problem Based Animations which create visual models of the classic problems of concurrency, with the Dining Philosophers being by far the most prevalent, and Finite State Machine Visualisations which provide learners with graphical representations of mathematical models which they have created. These visualisations present an opportunity for learners to gain a new visual perspective on the issues that they regularly face. This approach has the potential a major barrier for learners, who struggle to place the issues of Concurrency within a context. This issue is well illustrated by the following quote from a learner – “The main problem in trying to learn the concurrent paradigm is trying to imagine processes occurring simultaneously. As the human mind can only concentrate on one thing at a time it is very difficult to keep track on all the actions taking place in a concurrent process” (Traxler 1994).
2.3.6.1 Problem Based Animations These animations aim to provide the learner with a graphical representation of the basic problems of concurrency. These animation range from describing singular access to a shared resource (numerous cars crossing a single lane bridge) to representations of the classic problems of concurrency (the Sleeping Barber). At a stretch, the ‘Little Man Computers’ can also be included in these categorisation. Though some implementations are strictly sequential, there are a number which require the ‘little man’, the operating system, to deal with interactions from numerous processes simultaneously (Yurcik 2001). However, by far the most prevalent animation is that of the Dining Philosophers. The animations themselves come in a variety of guises and but be characterised as static animations - predetermined instructional demonstrations of a particular problem. These static animations are by far the most common, but they are also the least pedagogically inspired. By allowing learners to simply view a simulation, learners are not given the opportunity to explore and experiment with their own understanding of the environment. The example introduced can be described as one of the more complex, as it allows for more flexibility than the majority of animations available.
28 Developed at Drexel University 3, using XtangoAnimator, this visual representation of the Dining Philosophers is accessible through the web, and is built in the form of an applet. Here the learners predefine certain rules to their model – how many philosophers there will be and how long it will take for them to get hungry. Having set the initial variables, the learner can start the simulation.
Figure 5: Visual Philosophers Each philosopher is represented by a circle, with their forks being represented by grey lines. The snapshot seen in Figure 5 describes two philosophers, 0 and 3, eating. The number 2 philosopher is hungry, but will not pick up any forks until he can gain both forks necessary – therefore, he is waiting on philosopher 3 to finish eating before he proceeds. This tool fulfils the goals of animation, by providing a dynamic graphical representation of the world of the dining philosophers. It provides learners with the advantage of being able to graphically see the actions of the system globally. The aim of this is to present the information within a relevant context for the learner. It does not however facilitate constructivist learning, as the learner is not scaffolded to engage in actively seeking a solution – they are simply presented with a visual description of how a system would behave under certain conditions.
3 Available at - https://www.cs.drexel.edu/~shartley/ConcProgJava/Applets/diningPhilosophers.html
29 2.3.6.2 Finite State Machine Representations Finite State Machines (FSM), also known as Finite State Automaton, allows learners to develop their own multi-state environments or more specifically a mathematical representation of the systems they wish to create. These models describe the components that are most relevant to concurrent systems, in particular data representation, resource allocation and user interaction. As the model is a description of an abstract mathematical formula, it can be presented in a number of different visualisations, the most common being the Markov State Diagram. By correctly describing the system, it is possible to check the system against the issues of concurrency. For example, it is possible to check the FSM to see if there is a possible state where there are no valid actions, meaning there is no possibility of deadlock. Though extremely valuable, these tools require the learner to understand a new way of describing systems. They must understand the nuances of finite state machines to describe systems appropriately, and alter the systems if the verification tools suggest that a concurrent issue could occur. As mentioned, the visualisations are representations of an abstract mathematical model, which means that they don’t represent the issues of concurrency within the context which they occur. In this way, they don’t support the learner to visualise the practical reality of concurrent systems. One example of this style of application is Magee and Kramer’s LTSA analyser. This tool, which is provided as an addition to their book (Magee 2000), allows learners to write applications in pseudocode, have those models translated into Finite State Machines and analysed for the properties of safety and liveness. This tool is presented as a “verification tool for concurrent systems” rather than a tool for helping learners visualise the issues of concurrency.
30
Figure 6: LTS Analyser Figure 6 shows the LTSA in use. The analyser had compiled the following pseudocode: Code Fragment 3: Countdown Timer
COUNTDOWN (N=3) = (start-> COUNTDOWN[N]), COUNTDOWN[i:0..N] = (when(i>0) tick-> COUNTDOWN[i-1]
|when(i==0) beep -> STOP
|stop-> STOP
). This algorithm describes a timer ticking down to 0. As can be seen in Figure X, the analyser has identified a ‘potential DEADLOCK’ situation – which is when the clock reaches 0. The LTSA system also provides the learner with a Markov State Diagram to represent visually the FSM. By verifying the algorithm and providing the learners with an interactive representation of their model, this tool provides learners with the opportunity to explore and experiment with their mathematical model. This model however only represented the states associated with the actions of a system when given the described specific instructions. The tool does not try to support the learner
31 in gaining insights into the general concepts of concurrency; it supports the verification and visualisation of a system under a certain algorithm.
2.3.7 Temporal Logic There have been other approaches to teaching and learning concurrency, mainly focusing on the use of temporal logic. This strand of mathematics models real systems around logical objects. By representing a system as a ‘behaviour’ (a sequence of states) it is possible to check a system for safety and liveness properties. This is made possible by checking the ‘behaviour’ through every possible execution, ensuring that no error state is reachable. As always, the barriers-to-entry to this approach are high – requiring both a thorough understanding of the nuances of temporal logic and the ability to describe it using the appropriate notation. The notation must appear quite intimidating to a novice. For example, Lamport describes the following pseudocode (Lamport 1994) Code Fragment 4: Lamport’s Loop
Initially x = 0; Loop forever x := x + 1 end loop in temporal logic (Lamport 1994) as follows:
Similar to FSM, this approach is valuable for describing and verifying concurrent systems – but it assumes the ability on the part of the learner to translate the mathematical representation of a specific problem into a solution of a problem they might face in designing a computer system.
2.4 Conclusion
Concurrency is a complicated subject area which is difficult to teach and to learn. The topic itself is fundamental to modern computer science, describing how machines manage the running of multiple concurrent tasks. The aim of the study of concurrent systems is to provide the learner with the ability to identify the main problems in concurrency (deadlock, starvation, fairness and mutual exclusion) and the capacity to apply the appropriate mechanisms (semaphores, monitors and message passing) to
32 ensure the properties of safety and liveness. Approaches to the teaching and learning of concurrency have mainly focused on the instructional paradigm of lecturers, often in combination with more student centred tutorials. This combination, while beneficial for introducing a topic to a wide number of students, is not particularly suitable for engaging learners in gaining an in-depth understanding of a complex topic such as concurrency. For historical reasons, Concurrency is normally taught within in the context of Operating Systems. However, as the importance of concurrency has grown, a number of other approaches have been used to engage learners. These approaches range from presenting learners with non-technical problems that describe the issues of concurrency, to mathematical models which represent the behaviour of systems under certain conditions. These approaches, which each bring their own benefits, do not provide learners with a basic entry point for engaging with the broad concepts. Each approach either requires the learner to develop other skills, such as a specific programming language, or does not allow the learner to actively engage with the concept. There is clearly still a need to provide learners with a tool which reduces the barriers to entry for learning and also allows them to actively engage with the models and construct their own understanding of the issues and mechanisms of concurrency.
33 3. THE USE OF HANDHELD TECHNOLOGY IN LEARNING 4
3.1 Introduction
The objective of this thesis is to explore educationally appropriate uses of handheld technology to support learners in understanding and applying the concepts of concurrency. Having reviewed the current approaches to teaching and learning concurrency, it is clear that new thinking and innovative approaches are required to support learners in understanding the fundamentals of concurrency. One opportunity identified is provided by the increased integration of technology into education. As the review of teaching approaches has shown, there are already some new approaches being developed to support learners through the use of fixed personal computers – with a number of simulations currently available. One area which has not been explored for supporting concurrency is the use of mobile technology. However, many authors are arguing that the growth of pervasive computing will have a large impact on learning. For example Bull et al claim that it is inevitable that every student will have a portable wireless device (Bull 2002). In the U.S.A. the National Technology Leadership Summit, of the teacher educator associations, claims that “ubiquitous computing will be a widespread force in schools by the end of the decade or sooner” (Bull 2002). While, Pownell and Bailey claim that this evolution is part of the fourth wave in the evolution of technology with very small computers and wireless connectivity delivering ‘anyone, any time, anywhere learning’ (Pownell 2000) Given that change in educational approaches and up take of new technologies in learning are notoriously slow, these statements could be reasonably described as hopeful. They also reflect a certain degree of technological determinism, with the method of delivery – mobile technology – becoming as important as the goal itself - improved learning. However, they also echo the opinion that there are sound reasons to believe that handheld devices will have a role to play in the way we learn (Tinker 1997; Soloway 2001; Roschelle 2003; Naismith 2005). In particular, the “ready at
4 Much of this chapter is based on the work of a paper, (Patten 2005), accepted for the journal Computers & Education.
34 hand" nature of mobile devices means they can be used in authentic situated tasks. This integration of technology into the learning environment offers numerous opportunities to encourage learners to engage in new ways around the device. Similarly, the inbuilt communication capabilities mean that collaboration between devices can be supported. Outside of the field of concurrency, there have been numerous attempts to leverage mobile technology to support learning. These research projects and applications have supported a wide number of learning domains and functions, ranging from facilitating time management (Sharples 2000) to supporting language acquisition (Zurita 2004). Much of the research cites cost, adaptability and scalability among the motivations for using handhelds; however it must be remembered that - as in all learning - the use of technology must be driven by pedagogical considerations rather then financial, logistical or technical reasons. For this reason, the author decided to investigate the current use of mobile technology in learning, specifically the appropriate synthesis of technological capability and educational underpinning. To aid this investigation, a functional framework, or classification scheme for handheld applications, was been developed. The results of this investigation informed the design and implementation of a mobile application, which would make full use of the unique attributes of handheld devices in order to facilitate the teaching and learning of concurrency in a pedagogically sensible manner.
3.2 Background
Currently the most popular applications for handhelds are referential or presentational in nature, with dictionaries and organizers being widely available. There are however a wide range of educational applications that are neither referential nor focused on content delivery. Such applications range from electronic flash cards, which allow learners to test their knowledge of an area, to technologically augmented environments that enable learners to explore and interact with their surroundings. Due to the rapid, and continuous, changes in the PDA and mobile phone markets the devices used to deliver these applications vary widely. However the two markets are converging. So called smartphones now come with the extra facilities traditionally associated with PDAs, e.g. Internet access, video, and a variety of application
35 programs. On the other hand, PDAs are beginning to incorporate telephony functionality. Within these markets there are a number of different software platforms vying for market share. The most prominent are Microsoft CE, Palm OS and Symbian OS. This lack of a common platform leads to difficulty in delivering large-scale solutions, and has led some researchers to call for more standardization (Roschelle 2003). However, if the history of computer standardisation is anything to go by, it is more likely that the final “standards” in the area will be set by market forces rather than pedagogical needs. In any event, the functionality of handheld devices, both PDAs and ‘smartphones’, are constantly increasing, moving them from the market of electronic diaries to that of small laptops. Given their relatively low cost, wide variety of applications and the improved functionality of handheld devices it is becoming more feasible to provide every student with a personal device. This would address one of the major issues in technology and learning, namely allowing learners ‘ownership’ of a computer with permanent (ready-at-hand) access in and out of the official settings of an educational institution (Robertson 1997). Providing full time, ‘personal’ access to technology would offer new learning possibilities – particularly in supporting flexible ‘cycles of doing and reflecting’ and collaboration. Soloway et al . (Soloway 2001) presented mounting evidence that daily, pervasive use of computing leads to increased learning.
3.3 Classifications
A number of researchers have made attempts to devise classification schemes for this emerging field. The scheme devised by Gay et al, (Gay 2002), differentiates between applications based upon the educational objectives which motivate their use. These objectives range from ‘productivity’, which can be supported by the simplest tools, to ‘communication and collaboration’ which require complex applications. Roschelle on the other hand differentiates solely upon activity claiming that instances of the three main types, namely classroom response systems, participatory simulations and collaborative data gathering, have been implemented many times, (Roschelle 2003). Most recently Naismith et al., (Naismith 2005), divided applications based upon the educational theory that they support. The “theory-based categories” identified were behaviourist, constructivist, situated, collaborative and ‘informal and lifelong’. While each of these classifications have their merits, they tend towards a solely activity based or educational theory based perspective. To guide the development of an
36 educationally inspired and technologically appropriate solution a more extensive classification is required; one which merges these two perspectives into one framework – categorising the applications by activity, while also reviewing their pedagogical underpinning.
3.4 Functionality Framework
Upon reviewing the relevant research and experimenting with many of the applications commercially available, a framework for handheld educational applications was developed. This framework categorises applications by their function, and then reviews what, if any, educational pedagogy underpins each of the categories identified. The categories range from administrative applications, that are not driven by any real pedagogical philosophy, to collaborative applications that encourage knowledge sharing while making use of the learner’s physical context and mobility. The full list is as follows: Administration Referential Interactive Micro-world Data Collection o Scientific - Multimedia - Reflective Location-Aware Collaborative There is a progression between the categories identified, with each one generally incorporating some of the functionality of what has appeared before it. The initial categories provide services that we believe could equally be provided by either fixed desktop computers or laptop devices, while the later categories leverage off the unique attributes of handheld devices. A pictorial overview of the framework is given in Figure 7 – with the following paragraphs describing each category, and sample applications from within that category, in turn. Each of the categories is introduced, with examples of applications in the category being highlighted. The pedagogical philosophy that lies behind their implementation is also reviewed.
37
Figure 7: Functionality Framework
3.4.1 Administration Administrative applications, which focus on information storage and retrieval, are widely available. Generally concentrating on scheduling, calendars and grading, these devices could be described as education focused Personal Information Managers. An example of a popular application in this area is the ‘Due Yesterday Student Organiser 5’ - which allows students to schedule assignments, classes and study periods. Other applications, broadly described as groupware, make use of some of the communication features handheld devices offer, by allowing users to share their calendars and co-ordinate schedules. These administrative applications have little pedagogical philosophy underpinning their implementation. Building upon the initial ‘Personal Organiser’ functionality of PDAs, they focus on information storage and retrieval for the educational domain and do not attempt to scaffold or support knowledge construction. While these tools have their uses, specifically around time management and logistics, they do not facilitate learning or encourage learners to engage with topics.
5 http://nosleepsoftware.sourceforge.net/index.php
38 3.4.2 Reference Referential applications – which include a wide range of ‘office style’ tools, dictionaries, translators and e-books – allow for the accessing of content at the place where learning activities occur, making use of the portability of handheld devices. While often including some basic administrative functionality, such as note-taking, these applications, such as ‘Microsoft Reader’ 6 and ‘Adobe Reader’ 7, generally do not move past information delivery. Similar applications such as MS Pocket Word 8 and ‘Documents-to-Go’ 9 allows for users to store, access and annotate documents that they normally access on their desktop computers. This accessibility to information is also used for a variety of ‘Just-in-Time’ applications which support learning in work environments. All of these applications make use of the mobility of handheld devices – delivering large amounts of information and content to users in a portable manner. Though widely available, these applications are not particularly educationally inspired. Those applications with an underlying pedagogy are built upon an instructional philosophy to learning. They aim to support the learner by delivering large amounts of textual data onto a small and limited device . In general, these applications do not scaffold or support knowledge construction. The applications do provide learners with the potential to access content in ‘new’ spaces, areas where they previously did not have access to technical resources. For this reason, many of the tools are handheld versions of desktop applications and could be implemented with similar benefits on a number of different devices, if the issue of access to technology could be overcome. Some studies also question the benefits of this use of handheld devices due to, amongst other things, the well established usage patterns of reference books and other information sources (Smordal 2003).
3.4.3 Interactive Interactive applications move past information management and content delivery, and focus on engaging the user through a ‘response and feedback’ approach. They make use of the input as well as the output features of handheld devices. A major section of this category is made up of ‘drill and test’ type applications, such as the ‘Study Cards’
6 http://www.microsoft.com/reader/downloads/ppc.asp 7 http://www.adobe.com/products/acrobat/readermain.html 8 http://www.microsoft.com/windowsmobile/about/tours/ppc/2002/pocketword.mspx 9 http://www.palmone.com/us/solutions/personal/docstogo/
39 available for graphing calculators. These applications are aimed at encouraging memorization of information for individual learners through multiple choice style quizzes, with immediate feedback provided. Also within this category of interactive applications are Wireless Response Technologies, as made popular on TV game shows. Designed for use with a group of learners, a question is displayed or verbally posed, users select for a limited number of answers (A, B, C or D) and the aggregated answers are posted on a shared display. Other applications within this category have a less data-driven and more creative focus, leveraging the touch screen interface of many handheld devices. For example, through drawing a series of pictures, the Sketchy 10 application provides users with their own simple animations as a response. Similar to administrative and referential tools, applications in the interactive category make use of the mobility of handheld devices, allowing the learner to interact with applications in spaces where they would not normally have access to devices. Excluding the creative style applications, learners would be able to interact with the applications and receive similar benefits, if they could access the applications in the same context on a different device. From an educational perspective, applications in this domain cover a range of pedagogical approaches. The reason for this is that while they all take a ‘response and feedback’ approach, the type of interaction they hope to facilitate vary from behaviourist to developmental. The popular ‘drill and test’ systems can be immediately associated solely with a behaviourist learning style. Built on the belief that learning is enabled by building an association between a particular stimulus and a response, the interactions these applications require are often answers to multiple-choice quizzes. While this approach is particularly popular in e-learning systems, it does not take full advantage of the attributes of mobile devices and does not reflect the general move away from behaviourism within the domain of learning theory. As Naismith et al., (Naismith 2005), state this is a “fairly basic application of mobile devices in learning” as they can “provide more direct ways for learners to interact with materials in an authentic
10 http://goknow.com/Products/Sketchy/
40 learning context.” Some applications, such as the aforementioned Sketchy, have a more creative focus. Making use of the touch screen interface of many handheld devices, learners draw a series of pictures which are then played as an animation. These applications are engaging, provide valuable creative outlets and can support a variety of learning styles, including the developmental learning associated with children’s art.
3.4.4 Microworld Educational micro-worlds 11 engage learners by allowing them to construct their own knowledge through experimentation in constrained models of real world domains. By setting tasks within real world settings, learners are able to engage with topics in a novel and innovative manner. An example of this approach is ‘Carom Billiards’, which used the context of a billiards game to engage the learner in exploring some simple geometric theories (Horton 2002). Similar to the previous categories, these applications are aimed at individual usage and, if access to technology could be overcome, they could be replicated on desktop devices with many similar learning benefits. However, some of the attributes of these applications, their personal and tangible nature, are well suited to mobile devices. These applications can also make innovative use of the touch screen interface available with many handheld devices, which make them more appropriate for the technology. Applications within the Microworld category are more consistently pedagogically sound, based on constructionist learning theory. They encourage
11 A microworld is a virtual environment constituting the physical representation of a student’s ideas and understandings. (Papert 1980)
41 creation or exploration in an individual learner. One example of this approach is uDrumSteps, a mobile version of DrumSteps a novel software tool for percussion composition. Based firmly on the constructionist theory that learning occurs “especially well when the learner is engaged in constructing something for others to see” (Papert 1993), uDrumSteps enables learners to create, manipulate, edit and save original pieces of percussion music through an intuitive interface. Though uDrumSteps has some collaborative features, it is primarily aimed at individual learners exploring musical concepts. However, while microworlds can be abstractly regarded as technologically appropriate and educationally sound, issues remain. For one, due to the lack of microworlds currently available for handheld devices, there is little available data on their effectiveness for handheld devices. Also, the author’s experience would suggest that this approach can be educationally valuable, but given that microworlds are often technically sophisticated applications, the current limitations of handheld devices can reduce their educational impact. As the technology gains computational capacity, this constructionist approach should become more beneficial.
3.4.5 Data Collection Applications in this category make use of the ability of handheld devices to record data and information about their environment. Building on the administrative and referential categories, learners are generally able to access relevant content while also recording information. Within this theme, three categories of data are most common – Scientific, Reflective and Multimedia. Scientific: Scientific data collection focuses on encouraging the learner to learn more about their context through recording relevant information and providing immediate feedback through on-the-spot analysis. Most popular in Environmental Science, sensors are used to record real world data such as carbon monoxide readings. The use of mobile technology has been widely adopted by science educators and is well documented in the literature (Stanton Fraser 2005). The technology is particularly appropriate for this style of work, as the use of devices such as sensors are authentic to the task. Current implementations have a contextual focus, supporting the ‘field-trip’ nature
42 of the learning methodology. For example, the SENSE project developed applications to enable the devices to collect data and communicate with sensors that are ‘in the field’, while also providing feedback instantly through on the spot data analysis (Stanton Fraser 2005). This use of technology can be very beneficial, as the learning is taking place in a rich physical environment, filled with real world objects and connections, the presented concepts can be meaningfully contextualised (Falk 2000). Reflective: Applications in the ‘reflective’ category expand on previous themes, administrative and referential, allowing for learners to access content and diaries whilst also encouraging reflective practice. Most common in medical education, these applications encourage students to record observations in the setting in which they are working. These observations can then be used later for students to reflect on their learning (Anderson 2002). A typical project in this space is RAMBLE 12 (Remote Authoring of Mobile Blogs for Learning Environments). RAMBLE allows learners to record their observations on a handheld device ‘off- line’, when and where the learning activities occur, in this case on the wards of a hospital. Later the application will upload the observations to a ‘blog’, which can be reviewed by the learners and their supervisor. These applications are often built on simple technologies that encourage reflective social practice. A clear emphasis is placed on storing information in the learning context for evaluation and reflection later. While this approach is most common in medical studies, there has been research into its effective use in teacher training. In this scenario, reflections were made by the student teacher’s supervisor, while observing their supervisee in the classroom. The research found that it was a particularly effective tool for the facilitation of field notes during these observations, which were then used as a basis for feedback for the supervisee (Crippen 2000). These applications also often encourage collaboration, by enabling learners to share their reflections with a wider community through a number of different tools. This expansion is valuable, as the reflective process is an important component of collaboration (Brown 1989). Multimedia: Many new handheld devices are capable of capturing images, sound
12 http://ramble.oucs.ox.ac.uk/index.html
43 and video. This ability to capture information can be put to a number of uses. In the simplest case it is a form of note taking for classes or meetings. Such data can also be used as a basis for later reflection. Few devices have the software enhancements for on-the-spot analysis and reflection, so projects have relied on using a desktop application at a later stage. Another interesting approach is to use the multimedia capture capabilities of very low cost ubiquitous devices to facilitate digital creativity. The types of interaction that applications in the data collection category encourage are particularly well suited to mobile devices. The combination of communication features, computational capacity and the mobile nature of the devices would be difficult to replicate otherwise. Current implementations take a constructivist approach, requiring learners to construct new ideas or concepts based on their current and past knowledge (Bruner 1966). An example of this approach is the Digital Narrative Project 13 (McGreen 2005). Built on the belief that visual media is an exceptional medium for encouraging real-world problem solving (Smith 2000) and learners’ reflection (Bransford 1990), this project supports the participants to express their thoughts through a ‘Digital Narrative’. While the overall process is similar to other digital film projects, the tools used are different. Thus, the learners are able to access the multimedia facilities on the devices to shoot all of their “footage” and record their “soundtrack”. Due to current limitations in handhelds the final edit takes place on fixed PCs. As the incorporation of multimedia capability with handheld devices, particularly mobile phones, becomes more ubiquitous, the opportunity to use these devices to communicate in new ways, beyond those of telephony, will increase. In general terms, this category of application is more varied when it comes to pedagogical inspiration. Initial implementations in all sub-categories had little pedagogical basis, with the handheld devices being used as administrative assistants for logging data. More recent applications make more valuable uses of handheld devices in learning. They build on the attributes of the technology in ways that could not be replicated by other devices. This unobtrusive integration of technology into
13 The Digital Narrative: ‘Honey I Blew up the Planet’ website is available at http://blake.cs.tcd.ie/clubhouse05
44 authentic situated tasks fits in very well with what the philosopher Martin Heidegger described as objects that are “ready-at-hand” (available, within one’s reach and utilised). (Heidegger 1962) Generally, the technology plays a small and well-defined role of data collection, within a wider educational project built around strong social practice. Much of the actual learning, as Roschelle (Roschelle 2003) argues, is found in the design and debriefing phases of these projects, which is not mediated directly by technology.
3.4.6 Location Aware The applications under this category make use of some of the unique attributes of handheld devices. These applications, occasionally collaborative in nature, aim to enhance contextual learning activities by enabling the learner to interact appropriately with their environment. Going beyond the collection of environmental data, as done in the data collection category, these applications use sensors, or positioning systems (Bull 2002), to allow the devices to interact with the learner in a context aware manner - presenting appropriate referential information or promoting the learner to explore their environment. Applications in this area stretch from museum guides to augmented environments for treasure hunts. One example of the later is Ambient Wood, which encourages learners to construct their own understanding of a habitat through exploration (Cole 2003). Equipped with handheld devices, learners explored augmented woodland. Prompted by either a probe reading or positioning data, a relevant sound is played through speakers hidden in the habitat. Learners can then explore the habitat or review some relevant images and information which are available on the handheld device. This novel and innovative use of the technology uses the device to not only deliver content, but also to encourage the learner to engage more with their environment. The tool facilitates the learner to discover more, not on its screen but in the learner’s location, in a way that is only made possible through the use of personal mobile devices. The use of ‘location aware’ technology to interact with their environment is a contextual approach which can support a variety of learning styles. A popular implementation in this category, the basic museum guide, is instructional by nature, delivering content appropriate to the learner’s position. While this can occasionally be technologically complex, it has limited educational benefit. Some recent applications have focused on providing a stronger educational component, with the
45 aim of engaging a learner, or a group of learners, with their surroundings. This has led to novel solutions that encourage the learners to explore their environment through touch, sight and sound. The aforementioned Ambient Wood, which is both technically innovative and pedagogically sound, is an example of this type of project. The combination of location aware technologies and a contextual learning approach facilitates the learner to construct meaningful contextualisation of concepts, which has proven learning benefits (Michie 1998).
3.4.7 Collaborative Finally, and building on all the previous categories, a number of interesting applications have been developed in the area of ‘Collaboration’, in particular co- present collaboration. Applications in this category aim to encourage knowledge sharing while making use of the learner’s physical context and mobility. By making use of the mobility, communication features and computational capacity, these applications try to create a learning environment inspired by collaborative principles. Applications in this space include co-present problem solving games such as ‘Syllable’ (Zurita 2004), a learning environment aimed at young children learning to read and pronounce the alphabet. By working in groups of three, each member with a separate syllable, the learners must recognize and construct as many words as they can. When a word has been suggested, all members must agree on it being a word before it is evaluated. Through this process the young learners are able to construct words together and get immediate feedback on spelling and pronunciation. Some location based games, such as Savannah (Benford 2004) are also included in this category, as they include a strong collaborative component. In Savannah, learners use position sensitive handheld devices to ‘roam’ around a virtual savannah. By collaboratively completing ‘lion missions’ they construct an understanding of the issues faced by lions for their day-to-day survival. Building on the belief that learning is inherently a social activity (Vygotsky 1978; Roschelle 1995), these applications aim to facilitate learner collaboration . Applications in this final category are the most consistently pedagogically inspired. By making use of the unique attributes of handheld devices, these applications aim to support knowledge sharing between learners. A number of different approaches have been tried; with co-present games and collaborative contextual environments both proving educationally valuable. These implementations generally include many of the
46 positive elements of previous categories. The previously mentioned Savannah, for example, has a strong contextual approach associated with the ‘Location Aware’ category, with much of the collaboration based upon the learner’s precise position and the position of others in the environment. Likewise, Cooties 14 and Geney (Danesh 2001), two collaborative problem solving applications, have strong links to the constructionist ‘Microworlds’ explored earlier. From the analysis of current mobile learning research and applications, it is clear that the most educationally appropriate solutions currently available are built on a combination of collaborative, contextual, constructionist and constructivist principles.
3.5 Pedagogical Underpinning
Given the constant development of new features and functionality for handheld devices, it is understandable that the research agenda of the area is often focused around exploring the possibilities created by new technical capabilities. However, while there are many interesting technical opportunities associated with handheld devices, the use of technology in education settings must be based around pedagogical considerations. The challenge for this research area is to create solutions that are educationally appropriate, not technologically complex. As Roschelle describes, applications are often let down by a complex views of technology and simplistic views of social practice (Roschelle 2003). Having classified each application by their functionality, it was important to place equal emphasis on the pedagogy, if any, that underpins their implementation. A global perspective of the pedagogical underpinnings of the functionality framework can be reviewed in Figure 8. This perspective highlights that there is no correlation between a complex solution and an appropriate educational solution. Some of the most interesting applications, are the least technically complex and facilitate the learner to look away from their screen and engage with their surroundings and peers. These applications, which are particularly suited to learning, are facilitating collaboration and supporting the social practices associated with learning. The educational philosophies of collaboration, contextualization, constructionism and constructivism in particular seem well suited to handheld devices. These philosophies
14 http://goknow.com/Products/Cooties/
47 leverage off the ‘ready-at-hand’ nature of the tools and can provide an appropriate use of the technology
Figure 8 - Pedagogical Underpinning
3.6 Conclusion
Having reviewed the literature and numerous applications available in the domain, the following conclusions have been made:
• Much of the work presented, across the categories, has had limited success in the field. No ‘killer app’ for mobile learning, the application that will bring these devices into learning environments everywhere, has been found. However, progress has been made and lessons have been learnt.
• It seems that, despite the setbacks, there are sound reasons to believe that handheld devices will have a role to play in the way we learn. The extent to which this opportunity will be taken will depend on how the technology is used.
• Many applications currently available do not make use of the unique attributes of handheld devices and, if issues of access to technology are overcome, could be replicated on other devices with similar learning benefits.
• The applications that are particularly well suited to learning facilitate
48 communication between peers and support the social practices associated with learning. In particular the educational philosophies of collaboration, contextualization, constructionism and constructivism ( C4 ) are seem to synthesis a strong educational underpinning and an appropriate use of technology From this review, it is clear that there is an opportunity for developing an appropriate mobile solution for supporting learners in the teaching and learning of concurrency. The research would suggest that this tool should aim to support a C4 approach to learning and encourage communication between learners.
49 4. DESIGN
4.1 Introduction
Concurrency is a complex topic, which is difficult to teach and learn. Learners face numerous challenges, in both the topic itself and the way it is presented. In particular, learners find it difficult to apply the concepts of concurrency to solve new problems they encounter. One teaching approach that has gained acceptance in the literature, and has been widely simulated in software visualisations, is the use of problem based learning. Used appropriately, these problems – such as the Dining Philosophers - offer the opportunity to engage learners in active and independent learning. Against this backdrop, we have the increased importance of handheld devices in learning. These devices are becoming ubiquitous and offer a new entry point for engaging learners. Having reviewed the literature, it appears that the most educationally inspired applications are based on the C4 principles of collaboration, construction, contextualisation and constructivism. There is an opportunity to explore the use of an educationally inspired and technologically appropriate handheld application to support the teaching and learning of concurrency. Linking together these two threads, the author decided to develop a Concurrency Toolkit. This toolkit uses mobile technology to support learners in actively engaging with the concepts of concurrency within the context of its ‘classic problems’. This toolkit aims to provide learners with the opportunity to take the role of a process or behave like the mechanisms of concurrency, but place those roles within a neutral context – away from the barriers associated with programming languages or operating systems. Also, a learner will take only one role in the environment – they would be required to collaborate in order to simulate the system. They will also need to collaborate to ensure the proper running of the system – ensuring the properties of safety and liveness. Focusing on the classic problems had obvious curriculum integration advantages. However, as the research identified, simply being able to tackle these problems did not automatically provide the learner with the confidence or understanding to apply the concepts in new environments. For this reason, the toolkit would provide the learner with a ‘primitives’ facility. Here the learner would be able to access all the
50 basic mechanisms/primitives associated with concurrency – message passing, monitors, semaphores and timers. Using these mechanisms the learners would be able to collaborate in building their own multi-processing scenarios – they would have to demonstrate their understanding of the mechanisms by actively applying them in a new environment to ensure the correct running of a multi-process system. Having decided upon this course, the next challenge was to design the toolkit in a manner that ensured the toolkit would make appropriate use of the technology and support the C4 pedagogies. This chapter initially introduces the C4 pedagogies and identifies guidelines from the literature for developing these styles of applications. These general guidelines are then used to describe specific requirements to inform the design of an application for handheld devices, which facilitates the teaching and learning of concurrency in a pedagogically sensible manner. The chapter ends by outlining the design of the Concurrency Toolkit that supports learners in constructing their own understanding of the mechanisms of concurrency, within the context of the domain’s classic problems.
4.2 Pedagogy Guidelines
As previously mentioned, it is difficult to imagine learning approaches deviating greatly from the current combination of lectures and tutorials. To improve the learning opportunities for students, new tools must integrate into this environment. One beneficial innovation in this area has been the introduction of problem based learning, and the emphasis on knowledge being constructed by learners who actively engage in solving the task. As identified, this approach is not often used to its full potential – with problems often being used as exemplars rather than tools to engage learners. An opportunity identified by the author was to develop a tool which supported learners in actively constructing their own understanding of these problems. This tool could be easily integrated into the current curriculum. Having identified three of the most prominent ‘classic’ problems in concurrency – Mutual Exclusion, the Dining Philosophers and the Sleeping Barber – it was necessary to review the research around the C4 pedagogies, to identify any design guidelines that are available for building C4 style tools. These principles would then inform the requirements for developing the Concurrency Toolkit.
51 4.2.1 Contextual Contextual learning – also known as situated learning – places concepts in an appropriate environment. By placing the concepts in the situation or context in which the knowledge is used, learners can associate concrete meaning with abstract concepts (Brown 1989). Contextualisation often has a physical element, where the learning is taken out of an instructional environment, and placed in the actual physical environment for which the learning is intended. It is widely recognised that this physical contextualisation of learning, through field trips and similar methods is beneficial to the learner. This type of contextualisation provides the learner with hands-on, real world experiences, promotes positive attitudes to the learning topic and motivation towards the subject (Michie 1998). Because the learning takes place in rich physical environments, filled with real world objects and connections, the presented concepts/ideas are meaningfully contextualised (Innovation 2002). Handheld technologies have been used with particular benefit in the domain of science fieldwork, as mentioned in the functionality framework in Figure 7. The small and portable nature of the devices allow for the devices to be integrated unobtrusively into the physical environment. This integration offers opportunities to engage the learners in the environment which “includes the device but in not limited to the screen.” (Cole 2003) The role of a handheld tool to support contextual learning requires supporting a learner in applying and exploring abstract concepts in an appropriate environment. To facilitate this, Sharples (Sharples 2000) suggests that the tool must meet these requirements:
• The technology chosen should be highly portable, to support its use outside of the classroom/computer room. • It should be unobtrusive and easy to use, so that the learner can concentrate on the learning and not on operating the equipment. • It should be available anywhere, to provide the information to support learning in contexts outside of the classroom. • It should support communication anywhere, so that communication to teachers and peers is possible where and when it is needed.
52 4.2.2 Constructivism and Constructionism A learning style which places strong emphasis on the relevance of the context of learning is constructivism. This theory proposes that learners construct their own ‘knowledge’ by collaborating with others and their environment. Built on the work of Dewey and Piaget, this paradigm proposes that learning is an active process, with learners using their established mental models to organise and construct their own knowledge (Bruner 1966). These models provide a framework for experiences and allow learners to create their own hypotheses – their own understanding of the issues they face. This fits in well with Piaget’s work, which suggests that learning is when new experiences adjust these mental models (Piaget 1970). The role of the tutor is of particular importance in constructivism. The role of the tutor is not simply one of instruction, but helping learners reflect on their own mental processes and in adjusting their models. By providing this support, tutors increase the learner’s potential for improving their development level. This role was explored by Vygotsky (Vygotsky 1978) who proposed that experienced tutors could lead learners into more complex areas by providing appropriate intellectual scaffolding. Papert extended this paradigm by suggesting learners gain particular benefit in constructing something visible or physical. Specifically, he described this concept of constructionism as asserting “that constructivism occurs especially well when the learner is engaged in constructing something for others to see”. The collaborative, social and physical elements of constructivism and constructionism are well suited to mobile devices. In particular, the portable, personal and technical attributes of these devices support collaboration at a technical (Roth 2000) and social level (Inkpen 1999). Clearly however the role of the tutor is one which cannot be hard coded. The tool will be designed to support many of the positive elements of constructivism and constructionism, however, to be used to its optimal benefit, it will still require appropriate facilitation on the part of the tutor. There have been numerous attempts to provide guidelines in translating constructivist and constructionist principles into learning environments (Papert 1991; Honebein 1996; Savery 1996; Ferguson 2001). The following design guidelines are a synthesis of these suggestions:
• Learning should be relevant • Provide experience in and appreciation for multiple perspectives
53 • Maintain the authentic context of the learning task • Encourage metacognition and reflexive activities • Tutors' role is to challenge the students' thinking • Students' ideas should be tested against alternative views through social negotiation and collaborative learning groups • Be engaging • Involve building and experimentation • Be useful to novice and expert alike • Focus on knowledge construction, not reproduction
4.2.3 Collaboration Both constructivism and constructionism suggest that knowledge is constructed “within” the student, with the presence of others facilitating the process of reflection and internal construction of knowledge. Collaborative learning, on the other hand, is based upon the belief that learning is inherently a social activity (Vygotsky 1978; Roschelle 1995), shifting away from learning through disagreement and conflict and towards mutual engagement. In particular, it is the opinion that learning occurs most naturally when learners are working together to solve problems (Jonassen 1998). Through this collaboration, or ‘co-construction’, learners articulate their understanding of the problem being faced and their own solution. This articulation requires learners to reflect on their own knowledge, which leads to a better understanding of their own thinking process. It also requires significant mental effort and supports the deep processing of information (Brown 1989). Facilitating this collaboration within an appropriate physical context can give significant advantage to the learner (Rieger 1997). Another aspect of this physicality of collaboration is that “in many … settings people use their own mobility and the mobility of artefacts to coordinate their collaboration with one another.”(Luff 1998; Cole 2003). For an application to support collaborative learning, it should allow for knowledge sharing, while being conscious of the physical context and the mobility of the user and the tools they use. Clearly, some of this should be possible through the use of handheld technology. As Cole & Stanton describe “The mobility of these devices also opens up the potential for inter-group collaboration. Children can walk around,
54 maintaining the flexibility of interacting with many other children, rather than limiting their collaboration to those on the computer beside them” (Cole 2003). The device itself however should not attempt to be the sole source of collaboration, as Roschelle pointed out that in many applications for mobile devices “Much of the learning occurs in design and debriefing phases that are not mediated directly by the technology” (Roschelle 2003). That said, the literature has some specific suggestions around the main elements that should be satisfied in the creation of a collaborative learning environment. These are:
• task co-ordination and roles • synchronisation and sharing of information • interactivity to achieve shared goals • negotiation and discussion on the goals, and the progress towards those goals • Support for both individual and group outcome achievements (Dillenbourg 1999; Churchill 2001; Zurita 2003)
4.2.4 Review Clearly there are a number of overlaps in supporting Collaborative, Constructionist, Constructivist and Contextual learning. Each learning paradigm promotes what Dewey would describe as “active learning”, with an emphasis on engagement and reflection. Also, as the guidelines focus on facilitating similar styles of learning on handheld devices, there is redundancy around the guidelines for implementing certain technical and logistical features. For these reasons, the author reviewed the guidelines outlined and synthesised them under two heading – technology guidelines and task guidelines. Technology guidelines reflect the requirements from the device required for developing a C4 tool. They can be described as follows: Technology Guidelines
• The technology should be highly portable • It should be unobtrusive and easy to use • It should be available anywhere • Communication should be supported anywhere – through the technology or through social practice
55
Figure 9: Task Guidelines The task guidelines outline the requirements for designing a C4 pedagogically inspired tool. The task guidelines are broken into three broad categories associated with the tasks progression – Task Setting, Task Support and Task Evaluation. They are visually represented as part of the functional framework in Figure 9 and are defined in detail below: Task Setting
• Responsibilities should be assigned • Task should focus on solving real-world problems. • Task should be relevant to the learner within that environment • Task should allow for both individual and group outcome achievements Task Support
• Information should be shared and synchronised between learners • Tutors should facilitate negotiation and discussion on the task between learners, aimed at knowledge construction. • Tools should be provided that help learners to interpret multiple perspectives. Task Evaluation
• Evaluation should be used to encourage self-analysis • Negotiation and discussion on process and progress should be facilitated • Group and individual outcomes should be acknowledged
56 4.3 Designing the Toolkit
Having identified the general technical and task guidelines to be considered when designing a C4 tool, the next challenge was to apply those guidelines appropriately to the design of a C4 tool for supporting the teaching and learning of concurrency.
4.3.1 Technology Design Decisions To support the technology guidelines as outlined, the author decided to implement the toolkit using Portable Digital Assistants (PDAs). These devices provide the appropriate mixture of mobility and functionality – they are highly portable, intuitive to use and support technical communication through numerous channels. As previously mentioned, there is a convergence in the functionality of markets of mobile phones and PDAs; therefore it is not unreasonable to predict that any extra functionality available on PDAs will eventually become available on mobile phones. Also, the “ready-at-hand” nature of PDAs allows for the technology to be integrated unobtrusively into a learning environment. Therefore the mobility, technical facilities and ready-at-hand nature make PDAs the appropriate tool for developing the toolkit.
4.3.2 Task Design Decisions As mentioned, Concurrency has a number of well known and widely taught ‘classic problems’. The author decided to design the tasks around these classic problems. This offered obvious advantages around integration into curricula and also provided tasks that had stood the test of peer review and were likely to be relevant to learners away from the concurrency toolkit. In particular the author choose Mutual Exclusion, the Dining Philosophers and the Sleeping Barbers. These tasks embodied a wide range of issues. Mutual Exclusion is relevant for introducing semaphores and queuing, The Dining Philosophers introduces deadlock and cooperation, while The Sleeping Barber introduces monitors and fairness. The challenge was to design the toolkit to supersede current animations, by facilitating learners in engaging in C4 style learning while tackling these problems. The classic problems have been designed to represent a real-world non-technical problem which involves a number of stakeholders trying to gain access to a limited resource. However, these classic problems are normally presented in their entirely, and when simulated aimed at an individual learner. One decision made was to distribute the classic problem over a number of learners. The learners would be
57 required to communicate with each other to simulate the classic problems.
4.3.3 Task Setting Design Decisions i) Responsibilities should be assigned As the classic problems model a multi-processing environment, their design already includes a clear delineation of roles and responsibilities. Therefore, the toolkit models itself around the individual roles and responsibilities of each problem. - Mutual Exclusion In Mutual Exclusion there are two roles – the process and the resource. Theoretically there could be an infinite number of processes and a limited number of resources. The role of the process is to gain access to the resource, while the role of the resource is to ensure that a maximum of one process is accessing it at any given time. - Dining Philosophers There are two roles in the Dining Philosophers, that of a Philosopher and that of a Fork. The role of the Philosopher is to spend a certain amount of time thinking and a certain amount of time eating. To eat, the Philosopher is required to gain access to the Forks on his right and left. He can only pick up the Forks to his right and left. The role of the Fork is to make sure that it is being used by at most one Philosopher at any given time. In the scenario, there must be at least two Philosophers and always an equal number of Forks. - Sleeping Barber Again there are two roles in this scenario – the Barber and his Customers. The role of the Barber is to sleep or to cut hair. If there is a queue, the barber must select the next customer whose hair they wish to cut. The role of the Customer is to have their hair cut. If they arrive and find the Barber asleep, they wake him and sit in the Barber’s Chair. If the Barber is awake, they join the queue and wait to be called. If there is no room in the queue, they leave and come back at another time. Theoretically there can be an infinite number of Customers and a limited number of Barbers. In this implementation there should be at least two Customers and only one Barber. The space available in the Queue is limited to four. ii) Tasks should focus on solving real-world problems As previously identified, the positioning of Concurrency within the context of complex Operating Systems or Programming Languages presents numerous
58 challenges to learners. The Dining Philosophers and the Sleeping Barber were designed by Dijkstra to tackle this issue; they present the problems of concurrency within the context of real world problems – people eating around a table and queuing for the barbers. The toolkit modelled these environments as described. The problem of Mutual Exclusion on the other hand is regularly described in the context of Operating System processes and resources or Programming threads and critical sections. Therefore, a decision was made to place the concept in a more ‘real- world’ setting – in this case Bees (processes) and Flowers (resources). The role of the Bee would be to gain access to the Flower, while the Flower’s role would be to ensure that no more than one Bee had access at any given time. iii) Task should be relevant to the learner within that environment Again, the tasks of the Dining Philosophers and the Sleeping Barber are designed with inherent motivation for each role. The Philosopher needs to eat; therefore he needs to pick up the Forks. The Forks can’t be in two places at once; therefore they need to control their use. A Barber can only deal with one customer at a time, while a customer needs to get their haircut. Each role performs a number of tasks that are relevant to them in their environment. Similar motivation needed to be associated with the Flower/Bee scenario, to ensure it was relevant to the learner. To achieve this, the role of the Bee was modelled on the role of the Philosopher – if a Bee does not eat it will starve. It is therefore very relevant for a learner controlling the Bee to gain access to the Flower. iv) Tasks should allow for both individual and group outcome achievements As the classic problems simulate global issues in concurrency – the correct running of a multi-processing environment – they intrinsically support group, or global, outcomes. In Mutual Exclusion, these include the maintenance of a critical section and the fair access of numerous processes to a shared resource. In the Dining Philosophers the group outcome is one of Deadlock prevention – that at no stage are all the Philosophers stuck in a cycle awaiting a Fork. In the Sleeping Barber the global outcome is for as many Customers as possible to have their hair cut by the Barber in a fair manner. As the toolkit distributes the problems, it also supports individual outcomes. The Bee and Philosopher must eat to live. The Flower and Fork must insure that it is only accessed by one process (Bee/Philosopher) at a time. The Customer must try to get
59 his hair cut, while the Barber must manage his queue as he sees fit. If any user achieves these outcomes easily, the roles in the environment can be altered. For example, reducing the number of Flowers and increasing the number of Bees would further limit the resource and increase the demand, making both the individual and group outcomes more difficult to achieve.
4.3.4 Task Support Design Decisions The toolkit would also require learners to support a number of guidelines once the learners had started tackling the problems. i) Information should be shared and synchronised between learners Each task required communication between a number of role-players. For example, in the Mutual Exclusion task each Bee is required to communicate with at least one Flower. This communication could be summarised as the Bee checking the status of the Bee – is there someone already eating? The toolkit would support this – and all other similar queries across all of the tasks – through the use of the Infra Red (IR) capabilities of the handheld. The learners would also be given visual representations of their current status – for example whether their Bee was currently on the Flower. This would facilitate the learners in visually checking their own status and the status of other role-players. Changes in state – for example a Philosopher picking up a Fork – would require a synchronous transaction between the two relevant role-players. In the highlighted situation, this would involve the Philosopher asking the Fork for control & the Fork replying that it was available. Once that synchronous message had been agreed, the Philosopher would change its state to signify control of the Fork and the Fork changing its state to signify that it was no longer available for use. ii) Tutors should facilitate negotiation and discussion on the task between learners, aimed at knowledge construction. While this guideline could not be hardcoded into any artefact, the tool required the learners to communicate to gain access to resources – this discussion would require a certain degree of negotiation and discussion. The tutor should aim to support this communication with appropriate interventions. iii) Tools should be provided that help learners to interpret multiple perspectives. As previously mentioned, the design of the tasks involved the distribution of the roles
60 and responsibilities over a number of role-players. The toolkit would require learners to be able to alter the role that they played within an environment – so that they could actively engage in performing a number of different roles & therefore experiencing the environment from a number of different perspectives.
4.3.5 Task Evaluation Design Decisions The final set of guidelines relate to actions that take place after the task has been completed. i) Group and individual outcomes should be acknowledged To support the guidelines, the toolkit will require that each role-player would have a relevant ‘end state’ – which visually represented their final state. These states would represent their individual outcome. For example, if the Bee didn’t get access to the Flower – his end state would be represented by a dead Bee. To insure that an end state is reached, each task should provide the option of taking place within a defined timespan. This timespan would ensure that even when a circular issue, such as deadlock, arose the task would eventually complete. It would also add extra impetus to the learner; they would only have a limited amount of time to make decisions. The duration of this timespan should be flexible, though it should have a default value. ii) Evaluation should be used to encourage self-analysis This visual representation of an end state is of particular use when learners fail to complete a task. If they have not collaborated to successfully achieve the desired end result, they must review how they worked together and their own actions – and devise a more appropriate strategy for dealing with the problem faced. This new strategy could then be tested by the learners by retrying the task. This self-analysis would be supported through a mixture of the tool, with its visual representation of the role-player’s end state, and the facilitator, who would need to constructively facilitate the discussion. iii) Negotiation and discussion on process and progress should be facilitated The toolkit would not actively facilitate this overall negotiation and discussion; this would require appropriate facilitation by the tutor. The toolkit would act as a catalyst for this discussion and support learners in demonstrating their point by providing a ‘freeform’ version, where learners could demonstrate ideas without the constraints of
61 time pressure or in-built logical assumptions.
4.4 Describing the Toolkit
Having reviewed the appropriate educational underpinning and developed a set of guidelines, the Concurrency Toolkit could be described as a C4 tool for handheld devices, which introduces a group of novice and intermediate learners to the basic mechanisms of concurrency within the context of the domain’s classic problems. This toolkit will be broken up in to five separate tasks to describe the relevant issues. Task1 would introduce learners to the use of semaphores to support mutual exclusion, within the context of a number of Bees (processes) and Flowers (resources). Task2 would stay within the same context and problem, but would increase the functionality of the Flowers to include the concept of queuing. Task3 would introduce learners to the concept of Deadlock within the context of the Dining Philosophers. Learners would be able to use the toolkit to explore the use of monitors and semaphores in supporting the properties of safety and liveness. Task4 would introduce the learners to the Sleeping Barber problem. Here learners would have to apply their understanding of monitors and queuing to address issues associated with priority and fairness. Finally learners would make use of Task5, which would provide them with access to the basic mechanisms of concurrency – message passing, semaphores, and monitors – and allow them to create their own multi-processing environments. Tutors could use this tool to propose new scenarios and allow the learners to make use of the appropriate mechanisms to simulate and address the problem presented. Within each Task learners can assume a number of different roles. The aim of this is to provide learners with a number of different perspectives within each environment. For example within the Mutual Exclusion problem they can engage with the issues from the perspective of a process or a resource. Also, within each problem, learners are required to work together to simulate the environment. Describing the Mutual Exclusion task once more, the process must communicate with the resource if it is to survive. This technical communication is provided by the use of IR on the handheld devices. Finally, each Task has two settings – Game and Freeform. The Freeform setting provides the learner with the functionality associated with their role, and allows the learner to explore the environment as they wish. The game setting provides the
62 learners with the extra motivation of attempting to solve the problem within a set period of time. It also ensures that each role reaches an end point, for example if a process has reached a state of deadlock it will suffer the effects of starvation.
4.5 Conclusion
Building on the findings of previous chapters - specifically around the difficulty associated with the teaching and learning of Concurrency - the need for a new and innovative approach to supporting the learning of Concurrency was acknowledged. Given the increased importance of handheld devices in learning, a mobile application was identified as a providing a new opportunity for supporting learners. Based upon the research available, the pedagogical principles of Context, Constructionism, Constructivism and Collaboration (C4) were identified as making appropriate use of the device, while providing a strong educational underpinning. With this in mind, the previous chapter reviewed the literature surrounding these educational approaches. Having introduced each approach, a number of design guidelines were identified in the literature for supporting each pedagogical principle. These guidelines were then synthesised to describe the broad requirements for supporting a C4 style application. These guidelines were then applied to the design of the Concurrency Toolkit. Having taken these guidelines in mind, a description of the functionality of the toolkit is provided.
63 5. IMPLEMENTATION
5.1 Introduction
This chapter describes the steps taken in transferring the design guidelines presented and applying them to the practical implementation of a mobile artefact, the Concurrency Toolkit. In particular it discusses technical decisions made before the implementation, introduces the functionality of each component of the Toolkit and reviews the issues which arose during the implementation. As outlined previously, this thesis proposes that the most appropriate approach to supporting learners using handheld technology is built upon a contextual, constructivist, constructionist and collaborative pedagogy. With this in mind, and building on the design principles outlined previously, the toolkit requires a number of learners to take on a role within a concurrent environment, either in performing a task or managing a resource. By working together they simulate the behaviours, actions and problems associated with multi-processing in general, and concurrency in particular. The aim of this toolkit is to provide novice and intermediate learners with a scaffolded ‘sandbox’ where they can implement and experiment with the basic mechanisms of concurrency. The basic mechanisms introduced include semaphores, monitors and message passing. To support integration into current curricula, the Toolkit introduces some of these mechanisms within the context of the classic problems of concurrency – in particular the Dining Philosophers and the Sleeping Barber. The Toolkit is broken down into five separate tasks - the first four tasks highlight a concurrency concept, with the final task is aimed at allowing the learner to demonstrate their own understanding of these concepts. The toolkit is developed to work on Microsoft’s .NET Compact Framework. Written in the programming language C#, the toolkit can run on any device which uses Microsoft Pocket PC as its operating system, including PDAs and Smartphones. The entire application is standalone, and once downloaded will install automatically on the user’s device. The toolkit is aimed at mobile devices with IR (Infra-Red) capabilities. It uses the IR features to support inter-process communication, such as message passing.
64 5.2 Selecting a Platform
As previously identified, the markets for mobile phones and PDAs are subject to rapid and continuous change. Numerous vendors are constantly developing new devices with additional functionality, leading to a convergence of these two markets. In particular, mobile phone vendors have begun to release ‘smartphones’ with functionality previously associated with PDAs, for example Nokia’s latest 9500 Communicator 15 which provides a full keyboard and support for Microsoft Office. At the same time PDA manufacturers have been adding telephony functionality to their devices, as can be seen in Palm’s purchase of ‘Handspring’ 16 and their release of the Treo 650 17 , a device they market directly as a smartphone. However, there is still a major divergence around Operating Systems, with a number of different software platforms vying for market share. The most well-known are Microsoft CE, Palm OS and Symbian OS. Of these systems, Symbian is aimed specifically at ‘data-enabled mobile phones’ and is not prominent in the PDA market. Until its recent acquisition of Handspring, Palm took the opposite approach – aiming mainly at the PDA market, only recently moving its operating system into the area of mobile phones. Microsoft CE, of which Pocket PC is a specific version, has been aimed as a solution for both mobile phones and PDAs. Recent market figures indicate that Microsoft CE is by far the most popular platform 18 , and it is regarded as providing the most complex functionality (Wiggins 2004). Given this combination of wide spread use and technical capability, the Microsoft CE platform was selected as the most appropriate for developing an artefact on. This decision had a cascading effect on other technical choices. For example, the use of the CE platform necessitated the use of the Microsoft’s .NET Compact Framework. When development began on the applications outlined, there were no stable implementations of J2ME which would run on the devices. Given this, the Toolkit was developed using Microsoft’s .NET Compact Framework 1.0 The applications were tested using Dell X5 Axims.
15 http://www.europe.nokia.com/nokia/0,,54106,00.html
16 http://news.com.com/The+awkward+smart+phone+grows+up/2100-1041_3-5770044.html
17 http://www.palm.com/us/products/smartphones/treo650/
18 http://www.gartner.com/press_releases/asset_113913_11.html
65
5.3 Toolkit
Having decided on the device and the platform, there were a number of global design decisions. Firstly, for ease of development, it was deemed more efficient to break each component of the toolkit into a separate application. Therefore, each task is represented by a folder, which includes a number of applications related to the stakeholders in each problem. For example, to start the Dining Philosophers learners must open the Toolkit folder and select Task3. Inside that folder there are two applications – Philosopher and Fork. Dependant on what has been previously agreed, learners select the appropriate application. As each component was built separately, opening screens are an important opportunity to provide a standard structure that clearly links the applications together. With this in mind, a template was developed. This template provides learners with an initial screen that introduces details around the application they are using and access to a toolbar that is standard across all components. This toolbar gives learners access to two options – ‘Start’ and ‘Version’. The ‘Start’ option gives learners access to an introduction text to the task and the option to exit the application. The ‘Version’ option provides the learner with access to the two settings of each application, ‘Free Form’ and ‘Game’. The Free Form setting provides the learner with the functionality associated with their role, and allows the learner to explore the environment as they wish. The Game setting provides the learners with the extra motivation of attempting to solve the problem within a set period of time. It also ensures that each role reaches an end point, for example if a Philosopher is stuck in a state of deadlock state it will suffer the effects of starvation - death. This acknowledgement of individual achievement fits in with the design guidelines. To support a variety of settings, it was deemed appropriate to provide the learners with the option for changing the settings within each game. This option is explained in detail with each implementation, but for the purpose of the template it was decided to provide a ‘secret’ option where game settings could be altered. This can be accessed by holding down on the CRITE logo on the start page of each component. Another standard element of each component is their use of IR to support
66 communication. This proved to be difficult, as the .NET Compact Framework does not provide for generic serialization. Therefore, some general IR methods - findIRDevices(), StrToByteArray(string str), IRreceive(), IRSend(string str) - were implemented which provide that functionality. These methods are used extensively in each component. They are described as follows: findIRDevices : This method attempts to initially contact any other devices in its area. If it finds a device, it stores its ‘ID’ and ‘Name’ and returns the Boolean variable ‘true’. If it does not find a device, it will return the Boolean variable ‘false’. Each component will only attempt to send or receive a message if it has found an IR device. IRsend : If the device is attempting to send a message, it will attempt to use this method to transfer the passed in ‘string’ across to the selected device. To do this it will create an IrDA client with the standard service name “IrDAFtp” – this service name acts as a description of the channel and must match the service name used by the receiving device. Having successfully initialised the channel, IRsend converts the string to a byte array using StrToByteArray and passes the byte array along a Stream. Dependant on whether it successfully transferred the message, it will return ‘true’ or ‘false’ StrToByteArray : This method is used by the method IRsend to convert the message from a string to a byte array. IRreceive : This method initially sets up a stream waiting for a message from a device with the same device ID stored using findIRDevices and with the service name “IrDAFtp”. It then sits and waits until an appropriate IrDA client contacts it. It then receives the byte stream, converts it back into a string and returns the message to the method which called it. These methods form the backbone of the Toolkit – allowing each component to communicate with each other, as specified in the design guidelines. They also took a considerable amount of time to develop to a relatively stable implementation – due to the lack of documentation available on the topic and some issues associated with the Compact Framework, which are documented at the end of this chapter. To summarise, the toolkit provides a visual and technical template on which each component was built. This template includes a standard start page and toolbar, a standard approach to altering ‘hidden’ variables and a standard approach to supporting
67 IR communication.
5.4 Task1
As has been previously mentioned, Task1 is aimed at introducing learners to the issues of Mutual Exclusion using the concept of a semaphore. It also aims to provide a simple introduction to using the device and getting the learners used to communicating using IR. As outlined in the design chapter, this task and all of the others are broken into various role-players. This allows for learners to interact in the environment from a variety of perspectives. This specific task is broken into two components – the hungry Bee, who needs to get some honey, and the small Flower, who can only feed one Bee at a time.
5.4.1 Bee The format of the Bee is designed to be uncluttered and intuitive. The Free Form version provided two indicators of the Bees current state – an image in the top left of the screen and a status label on the bottom right. It also provides two large buttons to represent the two actions a Bee could take – it can ‘Eat’ (attempt to gain access to the Flower) or it can ‘Leave’ (notify the Flower it was finished and fly away). This means the Bee has two states – it could be flying or it could be eating. The Game setting adds a ‘Start’ button and a countdown clock, which provides learners with a visual cue for how long they had to complete the task. This means that the Bee can have an extra state – it could die of starvation. The default settings for the game provides the learners with a life span of 60 seconds, in which they were required to ‘Eat’ for 20 seconds. As previously mentioned, these settings could be altered.
The Bee’s various states were visually represented as follows:
Flying Eating Dead
68 5.4.2 Flower The format of the Flower is also designed to be clear and intuitive. The Flower in this task has little to do other than guarantee Mutual Exclusion. Its current state of use is represented using a graphical image of its state and a large colour panel which changes from green to red dependant on use. Underneath this panel is a large button, ‘Receive Message’, that calls the IRreceive method previously outlined.
Dependant on the state of the Flower, it is represented as follows:
Available Busy The Flower can not suffer any negative effects if it isn’t used in a specified time – therefore it is implemented solely in a Free Form version.
5.4.3 Exchanges The task is dependant upon the messages passed between each component during the game. These messages are broken down into three exchanges: Exchange 1: Bee sends message checking whether Flower is available. Flower responds no. Bee receives no; message appears on screen stating that they should try again later. Exchange 2: Bee sends message checking whether Flower is available. Flower responds yes. Flower immediately changes state once message sent. Bee receives yes, alters state and starts eating timer. Exchange 3: Bee is finished eating and sends message to Flower saying it is leaving. Flower receives message. Flower changes state and sends confirmation message.
69 Bee receives confirmation, alters state and stops eating timer.
5.5 Task2
As has been previously outlined, Task2 is quite similar to Task1, except for the functionality of the Flower. It is aimed at introducing learners to the issue of adding a queue to the functionality of a semaphore. The task itself is again broken into two components – the hungry Bee, who needs to get some honey, and the small Flower, who can only feed one Bee at a time.
5.5.1 Bee The Bee component has the same visual functionality as in Task1, except for one change – it can be waiting in a queue. This is visually described using the flying state image, with an alteration in the text of the status label. When a Bee is queuing, the status label reads – “I’m in the queue!”. An extra ‘Receive’ button also appears when the Bee is in the queue. This is pressed when the Bee is called from the queue to gain access to the Flower. It has the same Free Form and Game settings.
5.5.2 Flower In Task2 the functionality of the Flower has increased. Where previously there was a colour panel, there is now a datagrid. This datagrid provides a textual representation of the queue – displaying an ID for each message and the message which has been received. Learners can select a row of the datagrid and reply with a number of set responses – Wait, Start or Leave.
5.5.3 Exchanges Again, the key to the task are the messages passed between each component during the task. These messages are described as follows: Exchange 1: Bee sends message checking whether Flower is available and waits for response. Message appears in datagrid. Flower responds Start. Flower alters state and message is removed from the datagrid. Bee receives ‘Start’; alters state and starts eating timer. Exchange 2:
70 Bee sends message checking whether Flower is available. Bee waits for response. Message appears in datagrid. Flower responds Wait. Bee receives Wait; alters status Label; ‘Receive’ button appears. [Time passes] Flower is ready to allow Bee access. Bee presses ‘Receive’. Flower selects message from datagrid and selects ‘Start’. Flower alters state. Message removed from datagrid. Bee receives message, alters state and starts eating timer. Exchange 3: Bee is finished eating and sends message to Flower saying it is leaving. Message appears in datagrid. Flower selects message and replies confirming that the Bee has left. Flower changes state.
Bee receives confirmation, alters state and stops eating timer.
5.6 Task3
Task3 is modelled on the Dining Philosophers. The task is aimed at introducing learners to the concept of Deadlock and allowing them to explore their own approaches to supporting the properties of safety and liveness. In this problem there are two role-players – the Philosophers themselves and the Forks they use. The Philosophers are representative of processes, while the Forks represent the contentious resource which the Philosophers are trying to access.
5.6.1 Philosopher The role of the Philosopher is described using three separate images – the Philosopher himself, the Fork to his right and the Fork to his left. The Free Form version uses the combination of these images to represent the current state of a Philosopher – thinking, hungry or eating. By pushing down on each image, the Philosopher is given access to an appropriate action. For example, by pushing down on the image of a crossed out Fork, the Learner may attempt to ‘Pick Up’ the Fork. Alternatively, if they already have the Fork, they can push down on the image of the Fork and select ‘Put Down’, to notify that they are returning the Fork. The Game setting adds another potential state to the Philosopher, one of starvation.
71 By adding a ‘Start’ button and a countdown clock, learners are motivated to complete the task (to eat) within a specified amount of time (by default 60 seconds). To support this, learners are provided with a visual representation of the time they have left. The various states of a Philosopher are represented as follows:
Thinking Hungry Starving Eating Dead
5.6.2 Fork The role of the Fork is similar to the role of Flower in Task1, they act as a semaphore and have two states – they are either on the table and available for use, or in a Philosophers hand and not available. This is represented on the device through the use of a single image of the Fork. If the Fork is available it is seen clearly, when it is unavailable it has a red cross through it. To support communication, the component has three buttons – ‘Receive’, ‘Take’ and ‘Wait’. The ‘Receive’ button calls the IRreceive method previously outlined and displays the message in a text area underneath the Fork. Learners can then reply to the request by pressing either ‘Take’ or ‘Wait’, depending on the current status of the Fork. Like the Flower, the Fork can not suffer any negative effects from lack of use – therefore it is only implemented in a Free Form version.
5.6.3 Exchanges There were a number of potential exchanges between a Fork and a Philosopher; they are broken down as follows: Exchange 1: Philosopher requests access to the Fork. Philosopher awaits response. Message appears in text area and Fork replies ‘Wait’. Philosopher receives ‘Wait‘ message and notice appears on screen stating that they should try again later. Exchange 2: Philosopher requests access to the Fork. Philosopher awaits response.
72 Message appears in text area and Fork replies ‘Take’. Fork alters state. Philosopher receives ‘Take‘ message and alters state to signify it’s picked up the Fork. Exchange 3: Having picked up both Forks, the Philosopher can select ‘Eat’. This starts the eating timer. Exchange 4: Philosopher selects to return the Fork. Once message sent, Philosopher alters state and stops eating timer. Message appears in text area and Fork alters state.
5.7 Task4
Task4 is modelled on Dijkstra’s problem, the Sleeping Barber. The task is aimed at introducing learners to the nuances of fairness and prioritisation, allowing learners to experiment with different approaches to enable the efficient running of a fair system. In this problem there are two role-players – the Barber and his Customers. The Barber is representative of a monitor, while the Customers represent the processes queuing to gain access to a shared resource.
5.7.1 Customer The role of the Customer is similar, though more complex, to the role of a Bee in Task2. They must attempt to gain access to a resource, the Barber’s chair, and if it is not currently available they should attempt to join the queue till the resource becomes available. To represent this, the component again presents two representations of the current state of the Customer – an image in the top left hand corner of the screen and a label in the bottom right. The actions available to the Customer are represented by a series of buttons on the right hand side, they are – ‘Wake Barber’, ‘Join Queue’, ‘Go to Chair’ and ‘Leave Shop’. Again, the Game setting adds a ‘Start’ button and a countdown clock, which provides learners with a visual cue for how long they have to complete the task. Though admittedly not quite as elegant as previous analogies, if the Customer does not get her hair cut in the required time, she dies. The default setting for the game provides learners with a life span of 60 seconds, in which they were required to get their hair
73 cut once. As previously mentioned, these settings can be altered. The Customer’s various states were visually represented as follows:
Needing a Haircut Queuing Cutting New Haircut Deceased
5.7.2 Barber The role of the Barber is akin to that of a Flower in Task2. Though again their role is more complex. As defined in the problem, the Barber has two main activities – he is either sleeping or working. This is represented by an image of the barber in the bottom left hand side of the screen and through a status label on the bottom right of the screen. The queue is represented on the top of the screen, by a number of Customers visibly queuing. The queue is bound to a maximum of 4. If there are already four in the queue, other Customers are told to come back later. The Barber’s chair is also represented visually on the bottom right of the screen, signifying if the resource is currently in use. These images represent the various states:
Sleeping Empty Chair Ready Working
To support communication, the Barber has one button – ‘Receive’. This button calls the IRreceive method previously outlined and prompts the appropriate action (waking up the barber for example). Learners can also perform actions by pressing on different images. For example if there is a queue, it is possible to press down on a selected customer and call them over to the chair. It is also possible to press down on the ‘Working’ image and notify the Customer that the Barber is finished cutting her hair. The Barber does not suffer any negative effects from lack of work – therefore it is only implemented with a Free Form version.
74 5.7.3 Exchanges The exchanges between the Barber and Customer are by far the most complex. They can be broken down as follows: Exchange 1: Customer finds Barber asleep. Customer attempts to wake Barber and awaits response. Barber wakes up. Changes state and sends confirmation message. Customer receives message and changes state to signify they are in the chair. Exchange 2: Customer finds Barber working. Customer sends message to check whether there is room in the queue and awaits response. Barber receives message and if there is no room in queue responds that the Customer should come back another time. Customer receives message; notice appears on screen saying try again later. Exchange 3: Customer finds Barber working. Customer sends message to check whether there is room in the queue and awaits response. Barber receives message and, as there is room in queue, responds that the Customer is in the queue. Alters state to signify extra Customer in queue. Customer receives message; alters state to signify that they are now in the queue. Exchange 4: Barber finishes cutting hair of Customer. Signals to Customer that they can leave and alters state to signify that they are ready for next Customer. Customer receives message that they are finished. Alters state to signify new hair cut. Exchange 5: Barber selects next Customer from queue. Customer presses ‘Go to Chair’ button and awaits signal. Barber sends message and alters state to represent new Customer in chair and reduces queue by one.
75 Customer receives message and alters state to represent that they are in the chair.
5.8 Task5
The goal of Task5 is to provide learners with access to the basic mechanisms of concurrency. Learners can then use this functionality to construct their own multi- processing environments, separate to the standard problems normally presented. To model this appropriately, there is only one role player – that of a learner with use to all of the appropriate tools. This was represented by the ‘ Primitives ’ application, which provides learners with access to the basic mechanisms of concurrency – message passing, a semaphore, a counting semaphore, timers and a queue. There is little enforced functionality, as the aim of the component is to provide a very loose environment. The only standard setting is that associated with the queue, where learners can automatically select ‘Delete’, ‘Signal’ or ‘Wait’. Signal and Wait are standard responses, which can be altered in a similar manner to the Game settings. There are no standard exchanges; they must be created by the learners as appropriate.
5.9 Implementation Issues
There were a number of issues, particularly associated with implementing for an artefact for the Compact Framework. It provides limited functionality, such as the lack of serialisation, which provides extra and frustrating challenges for implementation. A simple yet illuminating example of this is the Compact Framework’s implementation of the stringA.equals(stringB) method. This should return a Boolean variable dependant upon the result of the function – does stringA equal stringB. This is presented as part of the API, and is used in a number of examples available on the Microsoft support webpage, but does not actually function correctly. When presented with the function stringA.equals(stringA), the method will return false. The ‘workaround’ for this is to employ a separate method – stringA.compareTo(stringB) – which returns a variable. This method works as described in the API. Numerous similar ‘minor’ issues occurred when coding using the Compact Framework, which presented endless barriers to the development of a stable application.
76 5.9.1 IR issues Another issue associated with the Compact Framework is the limited support for IR communication. In particular, when an application is awaiting a response from another device the entire application is frozen. For example, while a Customer is awaiting a signal from the Barber to call it from the queue, the Customer application is unresponsive to other inputs. It is even impossible to close the application, without directly removing it from the device’s memory. This presented a large number of implementation issues – as it is possible for learners to ‘freeze’ their machines if another learner does not act as they predict. The usual workaround for this issue is to deploy a separate thread, which would start a ‘watchdog timer’. This timer would ‘kill’ the thread awaiting a response after a defined period of time. Unfortunately, almost the entire System.Threading namespace has been removed from the Compact Framework. It does not support a thread being either suspended or aborted. This means there is no way of stopping a device from waiting for a message once the IRreceive method has been called.
5.9.2 Interface Issues There are a number of well documented issues associated with presenting issues on a limited device such as a PDA (Brewster 2002). This is also apparent in the implementation of the Toolkit. While the initial tasks are relatively uncluttered, the Sleeping Barber and the Primitives applications attempt to compress a large number of functions into a limited space. There are also some basic HCI issues – for example it is unclear to learners when they have pressed a Button. The Compact Framework does not support the colour of a button being changed. These issues are unfortunate, but will remain part of the background when dealing with new and limited devices.
5.10 Conclusions
This chapter introduced the functionality associated with the nine different applications, spread over 5 separate tasks, which make up the Concurrency Toolkit. These applications aimed to introduce learners to the basic mechanisms of concurrency within the context of the classic problems of the domain. Specifically, this chapter described the functionality and implementation of four applications associated with Mutual Exclusion (the Bees and Flowers), two applications associated with Deadlock (the Philosopher and Fork), two applications associated with Fairness
77 (the Barber and Customer) and one application which provided learners with access to the basic mechanisms of the domain (the Primitives). These applications were built with the guidelines outlined in the previous chapter in mind. Specifically, they all support for communication between devices; they all provide clear roles to each learner; they all acknowledge achievement (and failure) and they all support the learner in gaining multiple perspectives on each problem. The applications were all developed using C# and can run on any device which supports the .NET Compact Framework and has an IR mechanism.
78 6. EVALUATION & DISCUSSION
6.1 Introduction
This chapter describes the results of a number of tests performed using the Concurrency Toolkit. In particular it introduces the results of workshops with two tutorial groups. A multi-method approach, supporting a number of different approaches was used to evaluate these workshops, with the aim of collecting as much data as possible from a variety of perspectives. The approaches supported a methodological triangulation of qualitative and quantitative results from a user survey and an in-depth review of the videotapes of each session. Separate to these tutorial workshops, a pilot scheme was undertaken to gain initial feedback around presentation, logistics and the user interface. The results of these sessions are used to evaluate the Concurrency Toolkit against its stated aim – to provide a C4 tool for handheld devices, which introduce learners to the basic mechanisms of concurrency within the context of the domain’s classic problems. This evaluation is broken into two separate pieces of analysis – a review of the learning styles adopted by the learners to evaluate whether they took a C4 approach and an evaluation of the educational benefits to review whether the learners produced any positive learning outcomes.
6.2 Experiment Description
A group of 13 students from Trinity College Dublin participated in the research. These students were an opportunistic sample and were broken into two separate workgroups. Group A consisted of 6 students who had all just enrolled on their first year of the BA degree in Computer Science. These students were new to the field of Computer Science and had yet to be introduced to the concept of Concurrency. None had been taught programming. Group B consisted of 7 students in their fourth, and final, year of the BA ICT degree. These students had been introduced to the concept of Concurrency the previous year through parallel programming. They had also recently attended one lecture which introduced Concurrency within the context of Operating Systems. Each tutorial lasted for 90 minutes. Initially the tutor (the author) introduced the broad concept of Concurrency and presented some guidelines for using the Toolkit. A
79 copy of the presentation is available in Appendix B. Then each group began Task1. To allow learners to become familiar with the devices and the application, Task1 was initially presented in the freeform setting and within an environment of one Flower for every Bee. This meant that there was no shared resource, and therefore no issues with concurrency. Having completed this task, the Bees switched to the Game setting and the number of Flowers was reduced by one. Now four Bees were required to gain access to two Flowers. Having completed the Game, learners then discussed the problem; their approach to solving it and any improvements they would make. This, and the other discussions mentioned were facilitated when appropriate by the tutor. After experimenting with this problem, the scenario was repeated in Task2. Here the learner in control of the Flower is provided with the extra functionality of a queue. The task was repeated again in the Game setting with two Flowers and four Bees. Having experimented in this new environment, the learners again put down their devices and discussed what had happened. The next problem presented was the Dining Philosophers. Here, each learner took on the role of a Philosopher or a Fork. There were always three Philosophers and three Forks. The learners immediately explored the environment by selecting the Game setting and attempting to avoid starvation. Having completed this Game, the learners discussed their approach and implemented an updated strategy. This cycle continued until the learners completed the task to their satisfaction. The Sleeping Barber was then introduced, but due to time constraints, neither group explored this task in depth. Finally, the learners used the Primitives application to solve a problem regarding serialization – another perspective on Mutual Exclusion. This problem is outlined in Appendix B. Having completed this task, both groups filled out the evaluation questionnaire. The user evaluation took the form of a multiple choice questionnaire, and its design was heavily influenced by the work of Eileen Costelloe (Costelloe 2004). Each learner fully filled out their own questionnaire under the supervision of the author. A copy of the questionnaire is available in Appendix A.
6.3 A C4 Toolkit
The toolkit was designed to support the teaching and learning of concurrency in a pedagogically inspired and technologically appropriate manner. Specifically it
80 proposed to support learners in a C4 manner. To evaluate this claim, the learners’ interactions were analysed by videotape for any episodes which highlighted the learners taking a C4 approach to learning.
6.3.1 Contextual Contextual learning, or situated learning, was previously described as the placing of concepts in the situation or context in which the knowledge is used with the aim of providing the learner with hands-on, real world experiences (Brown 1989; Michie 1998). The artefact was implemented on PDAs as it would support learners in using their own mobility to engage with the environment and meaningfully contextualise the ideas presented. The toolkit provided an abstract environment, with a number of different scenarios possible. In each scenario the learners contextualised this abstract environment by announcing to others their role, technically communicating with others and using their own physicality to complete the task – it was visibly a hands-on experience.
Figure 10 : Group A attempt Task2 There were numerous exchanges where learners initiated the task by announcing their own roles and reviewing the roles of others. Here, for example, are the initial exchanges between learners in Group A while tackling Task2
L2 (Learner2): I’m a Flower [to all] L6: I’m a Flower [to L2] [L1 stretches across table to L6 and attempts to gain access to Flower] L2: I’m still a Flower!
81 L3: You’re a Flower? Then you can be my Flower. L2: Ready? [L3 gains access to the Flower at L2] Through this process, learners were attempting to gain an understanding of the broader context of the environment – while Learner2 knew that he was a Flower, he was interested in the roles of other learners and the broader context – specifically how many other Flowers there were and where the Bees were. Within each task the learners also frequently used their own physical presence to replicate the actions of the system. For example, in Figure 11 Learner2 and Learner4, both of whom are in the role of a Philosopher, are stretching to communicate with Learner3, who is in the role of a Fork. This interaction replicates the contention of two Philosophers picking up a shared fork.
Figure 11 : Picking up a Fork. Similar exchanges could be found with the learner acting as a Bee moving over to the Flower, to attempt to gain access. This exchange is analogous to the actions of a process in attempting to gain access to a resource; the process must find and communicate with the resource. Learners also physically replicated the challenges of concurrency, in particular the challenge of a number of processes trying to gain access to a limited resource. This was particularly well highlighted in Group A when attempting a semaphore approach on Task1. Here is their exchange
L1 and L3 are Bees. L2 is a Flower
82 [L2 turns back to L3 and L1 attempts to gain access to Flower] [L3 attempts to get device in front of Flower by stretching around L2, but points device at L1] L1: You’ve gone the wrong side [to L3] [L1 has gained access – so L3 is forced to wait]
L1: Ok, I’m done. [L1 draws back from L2] [L2 turns towards L3] L2: Eat! [L3’s head drops – groans] L2: So close L1: You’re one second short! L2: We’ve got a dead bee. Here Learner2 was acting as the Flower, while Learner1 and Learner3 were acting as Bees. Learner1 quickly gained initial access to the Flower, a fact that Learner3 took a moment to notice. Learner3 then tried to gain access, but couldn’t as the Flower was already being accessed. When Learner1 did release the Flower, Learner3 gained access but not in time. Having completed this task, a discussion around what had occurred was facilitated. When asked what improvements could have been made to the process, Learner2 suggested the following:
L2: Queuing. Tutor: Ok, so how would you do that or what would be the benefit of doing that? L2: Just means that, you’ve got 60 seconds and you only need to eat for 40 seconds – so as long as the flower is ready to receive, you just do one first and then don’t wait until the next one – just do the next one. Though Learner2 had never previously come across the concept of semaphores, his experience of not being able to access the resource meaningfully contextualised one of the issues associated with their implementation – that of busy waiting - and he was able to suggest an alternate approach – implementing a queue. This approach was facilitated using Task2, which the learners used successfully, enabling both Learner1 and Learner3 to survive within the same time period and environment. There were a number of incidents where the learners used the tool to support their learning in a contextual way. A number of learners identified this in their evaluations
83 as an attribute they found worthwhile. When asked why they would rather be introduced to the concepts of concurrency using the Toolkit rather then in a lecturing environment, learners commented:
“Easier to visualise the problem and its solution”
“Because it is easier to visualise than trying to imagine processes in your head” “Hands-on experience always proves to be a better learning technique (for me at least)” Having identified the episodes and the feedback from the learners, it is clear that the tool did support contextual learning.
6.3.2 Constructivism and Constructionism As previously mentioned, the toolkit was designed to support learners in taking a constructivist and constructionist approach to solving a problem. Therefore the toolkit design required the learners to actively create their own hypotheses around the issues they were facing, i.e. constructivism. The toolkit then facilitated the learners to test their understanding by building a physical realisation of their hypotheses through their actions, i.e. constructionism. An example of this could be seen in Group A’s approach to the Dining Philosophers. Having been introduced briefly to the problem for the first time, learners immediately began experimenting with the problem, by using the Toolkit to simulate the environment. Initially each Philosopher picked up the Fork to their right and a deadlocked state was quickly reached.
L1, L3 & L5 are Forks. L2, L4 & L6 are Philosophers. Each Philosopher has picked up the Fork to their right. L4: The Fork? [to L5] L5: I’ve given the Fork to him [L6] [L5 turns to L6]
L5: You [L6] give back the Fork. L2: So who has got the Forks at the moment? [to all] L4: I’ve got one. L2: Yeah – we’ve all got forks in our right. L5: Yeah. L4: So I’ll give you [L2] my fork and you can give them
84 L2: No. You need to eat for 20 seconds and I’ve only got 15 seconds left. I’m gone. [All Philosophers die of Starvation] Each of the Philosophers had suffered from starvation, as each Philosopher had picked up the Fork to their right – meaning no Philosopher could gain complete access and start eating. During a discussion immediately afterwards, the learners identified the problem and then suggested a solution.
Tutor: So what happened? L4: We all tried to get resources at the same time and we didn’t get enough. ………..
Tutor: How are we going to solve this? L2: Well we’ve got 60 seconds. And we’ve all got to eat for 20 – so one of us is definitely going to die. L4: No. You can take a Fork from Paul (L1) and John (L3). While that’s happening, I can get this Fork [points to L5]. Once you’re done, you can give me your Fork. Once I’m done I can give a Fork to him [L6]. L2: Ok, ok. We could do that. So who’s going to eat first? L5: No. There are only 3 Forks, so two people can’t eat at once. The most that will ever be eating is one person, so someone’s going to have to die – unless it was instant and it happened like... L4: Yeah, someone is going to have to die. L2: Because of the time it [the message passing] takes. By controlling access to each resource (scheduling), Learner4 was modelling one of the roles of a monitor. The learners also identified the inherent unfairness of the problem – due to the amount of time required for each Philosopher to eat, it would be impossible to insure that each Philosopher survived in the Game setting. Therefore, they tested their new approach in the Freeform version. Again, these learners had no previous exposure to the subject area. Having identified the problem and proposed a new solution, the learners then collaborated to test their theory, and used the toolkit to construct a physical model of the hypothesis. Through the toolkit’s task design and functionality the learners were supported in adjusting their own understanding of the environment and played out their hypothesis around how things should change.
85 This approach could also be seen in Group B’s approach to solving the same problem. They faced the initial same problem, with all of the Philosophers immediately suffering the effects of starvation. They described the problem as follows:
Tutor: Why did you die? L4: No resources. Tutor: What’s that called in a... L4: Starvation. Having previous knowledge of the area, they were able to describe the problem using more appropriate technical terms and were able to identify a number of different approaches to solving the problem, including a monitor.
Tutor: So what are the approaches to making sure that doesn’t happen? L4: Pre-emption. So you can say, if you’re a more important philosopher – let’s say. You can say to another philosopher – ‘give me your fork, I deserve it more.’ Or if someone comes in before you and they get the fork – you have to give it to them. Pre-emption basically means you can take a resource from someone else. ……….. [Discussion continues, with the problem flaw being mentioned and the asynchronous solution identified – see Collaboration heading for more details] ……….. Tutor: Is there a simpler way? L1: There’s a monitor. ……….. Tutor: So who’s the monitor? L1: It would need to be a controlling method or something. ……….. [Discussion continues and the monitor is described as a “maitre d’” ] ……….. Tutor: So we have a maitre d’ who is in charge of people eating. How will they act? L6: They’d be a global person, so they get all the information. He would know the solution, or she presumably. L4: They. They would be suspended above the table and they could see
86 everything. All: [Laugh] Tutor: And they wouldn’t be eating as you [L4] suggested earlier. L4: They’d just watch things. Monitor – it’s very aptly named. Tutor: So what are the drawbacks of that approach?
L6: More Overheads. L5: You need the extra resources of the monitor. They’d have to receive every message. L1: Yeah – everything has to be passed through the monitor. So you’re doubling up on the messages sent. Having identified the problem and suggested a solution, they used the Toolkit to model their solution and test their hypothesis.
L2, L4 & L6 are Forks. L3, L5 & L7 are Philosophers. L1 is acting as the monitor. Tutor: And we’re off [Starts Timer]. L1: Ok Brendan [L3] – you take those two Forks [L2 & L4]. Conor [L5], you take Conor’s Fork [L6]. L3: Ok, I’m eating. ……….. L3: Ok, which Fork do I put down first? [to L1] L1: Put down Shane’s [L4]. Shane you give your Fork to Conor [L5] L1: Tom [L7] – you pick up this [L2] ……….. L5: Which Fork do I give back? [to L1] L3: Well I’ve eaten, so I’m in no rush.
L1: Yeah. [Points to L6] [L5 now returns Fork to L6, allowing L7 to gain access and start eating]. Task Completed. The system maintained the properties of safety and liveness. Afterwards there was a short discussion.
Tutor: So what was different? Talk Monitor! L1: It was more organised. Less chaos basically. No one was taking forks
87 they couldn’t do anything with basically. There was a queued system going round based on where people were around who was going to eat first. Using the toolkit, Group B initially attempted the task and as Learner1 described “chaos” ensued - with all of the Philosophers suffered from starvation. The group then identified the problem and suggested a number of solutions. They then implemented one of these solutions, the monitor, resulting in a system that finished in a timely manner, allowed for Concurrency and safeguarded the properties of safety and liveness. This approach had a number of motivational benefits, with those learners identifying that they would prefer to be introduced to Concurrency through the use of the Toolkit rather than in a lecture environment commenting:
“I feel that introduction to concepts and ideas are easier when actually trying to use those concepts or ideas.” “In the toolkit environment you interact and think about what's happening more and get a better grasp of what's going on than by just taking notes” These comments and the examples outlined demonstrate that the learners found benefit in engaging in this active environment. They used the toolkit to test their understanding of the environment, adjust their understanding as appropriate and then demonstrate their new understanding by modelling their new hypothesis. Given these statements, it is reasonable to say the toolkit supported the learners in approaching the problems in a constructivist and constructionist fashion.
6.3.3 Collaboration The final pedagogical principle the Toolkit aimed to describe was that of Collaboration. In particular, it aimed to support learners in the process of mutual engagement and support social activity (Vygotsky 1978; Roschelle 1995). With this in mind, the Toolkit split each problem amongst a number of role-players - requiring learners to work together in simulating the environment. The technical level of this communication was supported by the IR functionality on the PDAs. This was apparent in the implementation of each task. Each task required the learners to, at a minimum, negotiate and communicate using their devices. This could be seen in each task and throughout both workshops. For example, when Group B attempted Task1 the following conversation happened immediately:
L3: Press receive?
88 L2: Yeah, press receive. L3: What did you get there? L3: [reading from screen] ‘Flower is available please press ok’ [L3 presses ok and looks at L2’s screen] [L2’s screen changes]
L2: Ah, deadly These interactions occurred frequently, with learners describing their interactions and occasionally commenting on them. Learners then began negotiating with their fellow learners to gain access to certain resources and began discussing the problem as well. In the following exchange, the same learners have moved on to Task2. After some initial technical exchanges, they move on to more task related comments.
L1 and L2 are working together as a Bee. L3 is a Flower. L4 is a Bee. L2: Press receive? L3: I’ve no idea. L2: Ok – receiving, receiving L3: Grand L2: [reading from screen] ‘Please point towards the appropriate user and press ok’. Ok. L1: Do they communicate when they are eating? [to L3] L2: Yeah, say Shane [L4] is on the Flower, do they [moves hands to demonstrate communication]? L3: No. L1: So if he’s [L2] gone to you and got on, he can take away the PDAs? L3: Yeah, I suppose.
L3: Yeah – so it’s back forth – back forth - that means he [L2] can eat. L1: So you [L3] can turn round to Shane [L4] and say ‘You get in the queue’. Then you turn back to him [L2]. Here, the learners started with social communication on top of the technical communication – they were simply describing the transaction. This social communication then became a platform for learners to work together to solve the problem – with each learner engaging with developing their understanding of the options available to the Flower when it has the functionality of a queue. As the
89 problems got more difficult and time sensitive this communication channel occasionally became more direct. This can be seen in this episode, where the same group are dealing with the Dining Philosophers:
L2: [reads from screen] ‘user requests the fork’ [L2 gives Fork to L3] L3: Great! [reading from screen] ‘You need both forks to eat’. L3: Give me the Fork [to L4] L4: Fork is gone L3: GIMME! L4: Sorry buddy. L3: put down your damn fork. [to L5] [L2 and L7 start to communicate] L3: No, your fork has gone [to L2] L2: I’m just telling him to wait L3: Can you tell me to wait? [to L4] [L3 and L4 point PDAs at each other] L3: [reading from screen] ‘Fork is already being used’ L4: I’m just sending you a message. L3: Give the fork back! [to L5] [L3 waits a few seconds] L3: [shouting] Conor [L5] relinquish the fork, I’m starving here! Here Learner3 starts off by describing the process, specifically around messages. Then he can’t get access to the Fork, the contentious resource, he makes his need known. He also is aware of the actions of the other learners and attempts to copy the process which Learner2 and Learner7 are engaged in. Learner3 and Learner4 then collaborate in performing and describing this transaction. He then expresses the urgency of his request to Learner5 by raising his voice. Clearly there were well established lines of communication between learners during the tasks, with a large number of learners actively putting forward their own understanding and actively engaging with each other. However, these discussions were brief – as each Task would only take roughly three minutes to complete. These conversations were continued as post task discussions. While not actively facilitating
90 these discussions, the Toolkit did act as a causal condition to support them. The following episode is a good example of this style of conversation:
The learners had just attempted the Game version of the Dining Philosophers – with all of the Philosophers dying of starvation. Learners were having a discussion around better approaches to solving the problem. Pre-emption had just been mentioned as an approach by L4. L1: Or you can base it on the position around the table.
Tutor: Ok, which is? L1: So Philosophers 2,4,6,8 and 10 are allowed to sit down and pick up their forks. So when they’re done, the odd numbered seats can sit down and pick up their forks. Tutor: Ok, how would you know that? L1: You’d be just checking to see if the fork had been put back yet. Tutor: Ok, but your Philosopher2 and all the forks are on the table initially, who decides? L4: Even ones take left then right. Then odd ones take right then left. Basically, if the even and odd take opposite forks initially it should work out. You’ll still have people not able to eat – but it should work out better because more people get to eat. Tutor: Is there a simpler way? L1: A monitor, use a ‘notify all’ method. Tutor: Where is the monitor? L4: The monitor would be the philosopher. Every time you pick up a fork you say ‘Wait, I’ve picked up a Fork’. When you put down the fork you say ‘Hey there’s a Fork here’ to the person next to you. Tutor: So that saying yes and no around each particular fork? L4: Yes, but each Philosopher would say – [pauses] – each philosopher has two forks and they share them. So I’ve a fork to my left and to my right and I share them with Brendan [L3] and Conor [L5]. If I’ve a fork and they want it, I say ‘Wait’, and when I’m finished eating, I put my right one down first and say ‘Hey Brendan [L3], I’ve put down the Fork’, and then I put down the left one and say ‘Hey Conor [L5], here’s the Fork’. Then they grab those forks and wait on the other forks. L6: So you’re only ever talking to your left and right?
91 L4: Yeah. ‘Cus there is no point in telling everyone that I’ve put down my left fork, since only one person can access to my left fork. And the same to my right. L6: [starts nodding in agreement]. Tutor: How much effect does your putting down one fork have on the system?
L4: One person. Well, at most affects two people. Me, as I’ve put it down, and the person who shares that fork with me. L1: But what if everyone is waiting on Shane [L4] to finish eating? Say if Shane [L4] is eating and say Will [L2] and Brendan [L3] pick up forks – then Brendan [L3] is waiting for Shane [L4]. So the two of them can’t eat until Brendan [L3] puts down the fork. So all the processes could die just because Shane is eating. So the resources can never be executed. Tutor: So him [L4] putting down a fork can have an effect L1: On everybody. Tutor: The whole system? L4: Yeah, but there is no point in telling everyone. Because the only one it matters to is Brendan [L3], the person that needs it. L1: Yeah, but we’re saying that it’s not the ‘notify’, it’s the methodology. L4: Big words! L1: But L4: Yeah – I know what you mean. This conversation covers a wide number of issues. It starts by Learner1 introducing an asynchronous approach to solving the issue of deadlock. This approach is not without its difficulties, as was later pointed out, but it is an interesting strategy. Learner4 attempted to build on the strategy and highlighted an algorithm for scheduling each Philosopher. The idea of a monitor is then introduced by Learner1. Again, Learner4 builds on this complex topic and provides his own explanation to the group. Learner6 seeks for clarification and provides a visual signal that he has understood. When questioned by the Tutor, Learner4 works through his logic – however Learner1 identifies an issue and raises it with Learner4. This conversation continued and together the learners developed a hypothesis they were happy with – which they then collaboratively constructed together. These conversations covered a wide number of issues with both groups, with learners
92 discussing issues ranging from their understanding of asynchronous message passing to the benefits of fairness in a system. The support for this style of learning received particularly positive feedback from the learners, with these being a sample of their responses from the evaluation:
“Much more interactive. Far better than the sage on stage.” “Talking in a group is more productive to solving problems” “More interactive and therefore easier to be involved” Analysis of the learner’s actions and their own responses suggest that the learners are engaged at various levels of collaboration. Initially they engage in technical collaboration and worked together to simulate the environment. Learners also engaged in more complex interactions, describing the technical system as they worked, but also adding comments around the process and attempting to dynamically alter the actions of other within the environment. Given the short space of time given for each task, roughly three minutes, these conversations continue into a post task discussion. Here some of the most in depth conversations occurred. Given these statements, it seems reasonable to state that the learners using the Toolkit actively engaged in collaborating with each other.
6.4 Educational Benefits
Having shown that the learners take a contextual, constructivist, constructionist and collaborative approach to engaging with the problems, the next statement to evaluate is whether the learners receive educational benefits by using this tool. In particular, did the learners gain an insight into the nuances of Concurrency? This is evaluated under two headings – firstly, around learner motivation and secondly around any concurrency related learning outcomes that the learners achieved. The learners’ motivation is evaluated through their responses in the questionnaire, while the learning outcomes are identified through an in-depth review of the learners’ actions during the workshop.
6.4.1 Motivation To analyse the students’ perceptions of the Toolkit, the questionnaire was specifically designed to gather information related to the following research question: To determine whether the learners considered the Toolkit to be useful in
93 supporting them in learning the basic mechanisms of Concurrency. In particular, the questionnaire focused on two particular issues: i) Learners’ thoughts about the use of the Toolkit compared to traditional approaches to introducing concurrency ii) Learners’ perceptions around the benefit of using the Toolkit. Complete results of the questionnaire can be found in Appendix C. To begin the questionnaire, learners were asked their opinion of the artefact. The vast majority of learners (92%) described the Toolkit as a ‘Very Good’ or ‘Excellent’ educational tool. No student felt the Toolkit was ‘Fair’ or ‘Poor’. When comparing the toolkit to other identified traditional approaches to introducing the topic, learners were also strongly favourable. In particular, they expressed a strong preference for using the artefact while being introduced to Concurrency (85%), ahead of a lecture environment (15%). There was also a consensus that it was easier to develop an understanding of the issues using the Toolkit, compared to a lecture environment – with 54% agreeing with the statement and 46% strongly agreeing with the statement. Also, a majority of learners (92%) felt that learning using the toolkit was more effective using the toolkit compared to learning in a lecturing/tutorial environment. They also found the Toolkit beneficial when compared to a standard tutorial environment, with the 85% agreeing or strongly agreeing with the proposition that the toolkit made them think more deeply about how they were going to solve the problem. Similarly, all learners agreed, with 62% of learners strongly agreeing, that the Toolkit made it easier for users to work together, compared to a standard tutorial environment. The learners also had strong views about the value of the Toolkit to their own understanding of Concurrency. All learners expressed the belief that, with the aid of the toolkit, their ability to design solutions for concurrent issues had improved. All learners also expressed the opinion that they had learnt from the experience of using the toolkit. While not proving knowledge acquisition on the part of the learner, these results do show that the learners’ own confidence in addressing the issues had increased. In addition to increased confidence, learners expressed high levels of motivation. When asked directly, 85% agreed or strongly agreed with the proposition that they felt
94 more motivated to learn when using the toolkit compared to other experiences with learning concurrency. 100% of learners stated that they enjoyed the experience of using the toolkit. Motivation could also be seen in their responses to questions around the potential of further use – with 85% expressing interest in using the toolkit as part of their studies if it were available, while the other 15% said they did not know. No learner said they would not use the toolkit if it were available. Having reviewed and analysed these responses it is clear that learners felt they benefited from using the artefact. In particular, they found it a useful learning tool that provided a more effective opportunity for learning, particularly at the introductory phase, compared with traditional lecture/tutorial approaches. The learners identified the toolkit as supporting their understanding of Concurrency and they were well motivated to continue learning with the tool. These results, in isolation, cannot support the generalisation that the toolkit increased the learners understanding of Concurrency. In particular, well-documented issues, such as the Hawthorne effect, often provide new technology and learning projects with feedback that is unrepresentative. For this reason, further research on larger samples for longer periods of time is required. These results do however suggest that the learners did consider the Toolkit to be useful in supporting them in learning the basic mechanisms of Concurrency.
6.4.2 Learning Outcomes The aim of this thesis is to develop an appropriate tool for supporting learners in gaining an understanding of the issues and nuances of Concurrency. For this reason, it was essential to evaluate what, if any, learning outcomes the learners achieved through using the toolkit. This question was evaluated from an in-depth review of the learners’ actions during the workshops. Starvation Both groups identified some issues around resource starvation when implementing Task1 and Task2. In particular they identified the issue of busy waiting when using semaphores and both groups suggested the addition of queuing, as mentioned previously in this chapter. When discussing Starvation in the Dining Philosophers, Group B made some very insightful comments around pre-emption prioritisation as approaches to addressing this issue:
95 Tutor: So it’s survival of the fittest? L4: The strongest will always win. L5: Bully out the weaker ones. L4: The weakest will always die first. L7: Well that’s not a fair system.
Tutor: If we don’t have a monitor, how can we stop that? L5: Well that could work, like, for a while. So long as not everyone is eating at the same time. L6: The weakest will always be at a disadvantage. L1: But if your priority is affected by the time you were waiting, so if you were waiting for 10 seconds – your priority went up 1 level. L6: So you have 2 values then? L1: You have to have a wait time. L6: So more overhead then? L1: Yeah. L4: If you’ve reset the priority once you’ve eaten L2: Yeah L4: Because if you’ve eaten and then you’re the biggest – you get to eat again – then you just get fat. But you’ll still be able to bully the weakest processes. L5: Go back to zero. Here, the learners have been discussing approaches to solving starvation, initially around the effects of pre-emption. Quickly they identify that this can lead to an unfair system. To counter this approach, the learners come up with a priority based system around how long each Philosopher has been waiting to eat. They also identify a problem which could prevent fairness and suggest a solution. Deadlock As previously identified, a common issue in Concurrent Systems is that of Deadlock. Both groups immediately suffered the effects of this when initially modelling the Dining Philosophers. As previously described, both groups described this issue and implemented monitor based approaches that scheduled access and prevented deadlock. Both groups clearly demonstrated their understanding of deadlock prevention.
96 Fairness As previously mentioned, Group A introduced the concept of prioritisation and fairer access during their discussion of starvation in Task1.
Tutor: Was the first task’s use of semaphores, fair?
L5: Well it’s most like nature, in that its first come, first served – but that’s not really what you want on a machine. Tutor: So what do you want on a machine? L2: Fairness. L5: You want everyone to work at the same time and together, and to be given equal resources. Well, not to be given equal resources – but according to how they need them. They make two interesting points, firstly around the unfair nature of ‘first come, first served’ approach and secondly around the allocation of resources according to need. This discussion led to the implementation of a queuing approach to solving Task2, that gave fair access of a resource to two processes. Semaphores Both groups identified the use of a semaphore to control access to a shared resource. While Group A did not have knowledge of the term, one learner did describe the functionality as an “on-off switch – one or zero”. Both groups applied this understanding when addressing the problem presented with Task5, supporting serialization. Both groups applied a combination of messaging and semaphores to insure that Bob ate after Alice. This was Group B’s description of their approach:
L4 [Alice]: Tell Bob not to eat. Tutor: Does he need to be told? L4: He needs to be told not to eat just yet, till I’ve finished mine – then I’ll tell him he can eat. Tutor: How do you know whether to eat or not? [to L5] L2: Use red or green. L5 [Bob]: Use this thing here [points to flag on application] Tutor: Grand, so you [L4] send your message and you [L5] set your semaphore appropriately, then what? L4: I eat lunch. I may or may not message him and say “I’ve eaten lunch, go ahead”.
97 Tutor: And what will you do? [to L5] L5: I’ll set this [flag] to green – I’ll eat and send back saying I’ve finished eating. Tutor: What have you done? L4: We’ve co-operated.
L6: You’ve brought control and organisation Tutor: What did you use? L1: A semaphore. Both groups successfully implemented this approach to insure an efficient and fair system. Monitors Both groups struggled initially with the Dining Philosopher, with all learners who took on the role of a Philosopher suffering starvation on the initial implementation. Both groups then identified the functionality of a monitor and replayed the Game, successfully modelling that approach. This can be seen in Figure 12, where the learner sitting furthest to the left is providing visual and verbal instructions to other learners, with the purpose of scheduling access to different resources – simulating the role of the monitor.
Figure 12 : Modelling a Monitor
6.5 Conclusion
This artefact was built with the stated aim of supporting learners in taking a C4
98 approach to learning the issues and mechanisms associated with Concurrency. Following an analysis of a questionnaire and an in-depth review of the learners’ actions during the workshops, the following conclusions are drawn. i) While using the Toolkit, the learners took a C4 approach. There were numerous occasions during both workshops where learners were involved in activities that could be classified as contextual, constructivist, constructionist and collaborative. The toolkit was either a component of this interaction, or a causal condition. ii) The learners felt they learnt about Concurrency by using the Toolkit. The feedback received through the questionnaires was remarkably positive. Learners stated clearly that they found the tool useful, that they felt they learnt from the experience and they would be interested in using it further in their studies. iii) The learners achieved valuable learning outcomes through the workshops A review of the learners’ interactions during both workshops highlighted a number of occasions where learners described and implemented solutions to some of the common issues of concurrency. Within the confines of a ninety minute workshop these occasions included the use of queuing to increase the efficiency and effectiveness of controlling access to a shared resource, the implementation of a monitor to manage the interaction of a system to prevent deadlock and the application of message passing and semaphores to insure serialisation in a system. Taking the triangulation of the different data gathering approaches into account, it is clear that the Toolkit had a positive impact on the learners. It supported the learners in adopting a C4 approach to their learning. Using this C4 approach, the learners applied the toolkit to demonstrate their new understanding of the issues of Concurrency.
99 7. CONCLUSION
7.1 Introduction
The stated objective of this thesis was to explore educationally appropriate uses of handheld technology to support learners in understanding and applying the concepts of concurrency. This was done through the development of a mobile artefact – the Concurrency Toolkit – that was designed with the pedagogical principles of contextualisation, constructivism, constructionism and collaboration (C4) in mind. Implemented on the .NET Compact Framework for handheld devices, the Toolkit can be run on any device that can support the appropriate Framework and has an IR mechanism. Following analysis and evaluation of a number of learners engaged with the tool, the following statements were made: i) While using the Toolkit, the learners took a C4 approach. ii) The learners felt they learnt about Concurrency by using the Toolkit. iii) The learners achieved valuable learning outcomes through the workshops.
7.2 Conclusion
It is clear that handheld technology can be used to support learners in gaining valuable educational benefits. This thesis proposes that the most appropriate synthesis of technical functionality and educational underpinning is found in the C4 paradigm. It is also noted that the devices did not actively facilitate some of the most valuable interactions – they acted as a causal condition to prompt learners into collaborating or reflecting on their own actions. There were also some valuable achievements from this research, including: - The development of a number of applications that can be easily integrated into a Computer Science Curriculum.
- The development of the Functionality Framework, a comprehensive categorisation of a dynamic domain. This work is currently pending publication in a special issue of the International Journal, Computers & Education.
100 7.3 Recommendations
With handheld devices truly becoming ubiquitous, there seems to be valid reasons to state that they will have some impact on learning. The strength and benefit of this impact will be dependant upon how these devices are used. Too often is the research focused solely on the latest technological advancement; the appropriate uses of these devices are to be found in the synthesis of appropriate use of technology and strong educational pedagogy. In particular, this research would suggest that there is much potential in using handheld technology to support strong social practice. Building on these statements, and the results of the evaluation, the following recommendations are made: i) Making appropriate use of handheld technology requires a synthesis of technology and educational underpinning. It is recommended that this educational underpinning should be based around the C4 paradigm and that the use of technology should be appropriate and unobtrusive to the task. ii) This research would suggest that there is real value in using handheld technology as a catalyst for further discussion. Those implementing artefacts for these devices should explore the potential of using these devices to prompt strong social practice. iii) It is noted that there is much potential for further research into appropriate strategies for the teaching and learning of Concurrency. It is regarded as a complex topic that proves difficult to many learners, yet its concepts are remarkably accessible and appear constantly in every day life.
101 APPENDIX A
Please answer all the following questions as honestly as possible. Place a tick beside your answer.
Name: ______
Group: ______
Q1. How do you rate the Concurrency Toolkit as an educational tool?
Excellent Very Good Good Fair Poor
Q2. The toolkit made it easier to develop an understanding of the classic problems of concurrency, compared to a lecture environment.
Strongly Agree Agree Neutral Disagree Strongly Disagree
102 Q3. The toolkit made it easier for users to work together, compared to a standard tutorial environment?
Excellent Very Good
Good Fair Poor Q4. Placing the issues of concurrency within the context of the classic problems made you think more deeply about how you were going to solve the problem.
Strongly Agree Agree Neutral Disagree Strongly Disagree
Q5. Using the toolkit made you think more deeply about how you were going to solve the problem, compared to a standard tutorial environment
Strongly Agree Agree Neutral Disagree Strongly Disagree Q7. How useful were the visualisations?
Excellent Very Good Good Fair Poor
103 Q8. How do you rate the usefulness of the game setting within the toolkit?
Excellent Very Good Good
Fair Poor Q9. Using the toolkit helped me gain an insight into multi-processing environments.
Strongly Agree Agree Neutral Disagree Strongly Disagree
Q10. Would you prefer to be introduced to the issues of concurrency using the toolkit rather than in a lecture environment?
Yes No Don’t know
Q11. If you answered Q10 yes – Why?
104 Q13. Before using the toolkit how would you rate your ability to apply the mechanisms of concurrency to solve its problems?
Excellent Very Good
Good Fair Poor
Q14. If the toolkit were available, would you use it as part of your studies?
Yes No Don’t know
Q15. Learning using the toolkit is more effective compared to learning from a description or reading a book on the topic.
Strongly Agree Agree Neutral Disagree Strongly Disagree Q16. Learning using the toolkit is more effective compared to learning in a lecturing/tutorial environment.
Strongly Agree Agree Neutral Disagree Strongly Disagree
105
Q17. Learning from the toolkit is more effective compared to learning from a simulation.
Strongly Agree
Agree Neutral Disagree Strongly Disagree
Q18. With the aid of the toolkit, how would you rate your ability in designing solutions for concurrency issues?
Improved Disimproved Same as previously
Q19. The toolkit made appropriate use of the handheld devices to support the tasks.
Strongly Agree Agree Neutral Disagree Strongly Disagree
106 Q20. How would you rate the usefulness of being able to simulate and manage a multi-process environment?
Excellent Very Good
Good Fair Poor
Q21. Did you enjoy the experience of using the toolkit?
Yes No Indifferent
Q22. The classic problems presented were appropriate descriptions of concurrency mechanisms.
Strongly Agree Agree Neutral Disagree Strongly Disagree
Q23. The toolkit was easy to use.
Strongly Agree Agree Neutral Disagree Strongly Disagree
107 Q24. Did you learn from the experience of using the toolkit?
Yes No Don’t know
Q25. I feel more motivated to learn when using the toolkit compared to other experiences with learning concurrency.
Strongly Agree Agree Neutral Disagree Strongly Disagree
Q26. Using the toolkit supported me in learning from my colleagues.
Strongly Agree Agree Neutral Disagree Strongly Disagree
108 APPENDIX B
Concurrency
Bryan Patten
Concurrency – the Basics
“Concurrency – A running together in place or time” A computer is required to do several things at the same time: Reading a position in from a mouse – while outputting to a screen & reading from a disk More complex examples – Enterprise Middleware, Operating Systems.. The goal is to allow numerous ‘tasks’ to run simultaneously and correctly.
109 Concurrency Toolkit
An artefact that supports learners to collaboratively engage in constructing their own understanding of the basic mechanisms of concurrency.
The toolkit facilites learners to simulate, control and create multi-processing environments.
The ground rules
Take your time..
Push buttons ONCE.
When appropriate, make sure whoever is ‘receiving’ has pressed ‘Receive’ first.
Make sure the devices are roughly aligned
Task 1 – The Bee & the Flower
Lets try the ‘FreeForm’ version first
2 Flowers & the rest bees
Then move onto the game..
What happened? What did the flowers see?
110 Task 2 – More Flowers & More Bees
Same again - ‘FreeForm’ version first
2 Flowers & the rest bees
Then move onto the game..
What happened? What was different?
Task 3 – Dining Philosophers
We need to sit around in a circle (no holding hands) Alternatively – we need a philosopher and then a fork! This time – lets try the game first.. What happened??? Thoughts/Suggestions?
Task 4 – The Sleeping Barber
Everyone up! 1 Barber & lots of customers.. Please forgive the graphics – they’re currently getting updated. Remember you can ‘regrow’ your hair after getting it cut by holding down on your character. Lets try the game..
111
Task 5 – the Primitives
Ok – no more philosophers/barbers/bees or flowers – just the tools we’ve been using.. 1st task – separate into pairs (Alice & Bob) Alice & Bob live in different cities. They can call each other. Assuming that Bob is willing to follow simple instructions, is there any way to guarantee that Alice will eat lunch before Bob?
Task 5 – Continued..
That was serialization and one of doing it is here: Alice Bob A1 Eat Breakfast B1 Eat Breakfast A2 Work B2 Wait for call A3 Eat Lunch B3 Eat Lunch A4 Call Bob
Next Task – How do you GUARANTEE that Alice & Bob don’t eat lunch at the same time – but they can eat in any order?
112 APPENDIX C
Percentage (%)
Q1. How do you rate the Concurrency Toolkit as an educational tool?
Excellent 15
Very Good 77
Good 8
Fair 0
Poor 0
"Q2. The toolkit made it easier to develop an understanding of the classic problems of concurrency, compared to a lecture environment."
Strongly Agree 46
Agree 54
Neutral 0
Disagree 0
Strongly Disagree 0
"Q3. The toolkit made it easier for users to work together, compared to a standard tutorial environment"
Excellent 62
Very Good 38
Good 0
Fair 0
Poor 0
113
Q4. Placing the issues of concurrency within the context of the classic problems made you think more deeply about how you were going to solve the problem.
Strongly Agree 23
Agree 54
Neutral 23
Disagree 0
Strongly Disagree 0
"Q5. Using the toolkit made you think more deeply about how you were going to solve the problem, compared to a standard tutorial environment"
Strongly Agree 23
Agree 62
Neutral 0
Disagree 15
Strongly Disagree 0
Q7. How useful were the visualisations?
Excellent 23
Very Good 38
Good 38
Fair 0
Poor 0
Q8. How do you rate the usefulness of the game setting within the toolkit?
114 Excellent 23
Very Good 31
Good 38
Fair 8
Poor 0
Q9. Using the toolkit helped me gain an insight into multi- processing environments.
Strongly Agree 38
Agree 54
Neutral 8
Disagree 0
Strongly Disagree 0
Q10. Would you prefer to be introduced to the issues of concurrency using the toolkit rather than in a lecture environment?
Yes 85
No 15
Don't Know 0
Q11. If you answered Q10 yes – Why?
Q13. Before using the toolkit how would you rate your ability to apply the mechanisms of concurrency to solve its problems?
Excellent 0
Very Good 0
Good 62
Fair 23
115 Poor 15
"Q14. If the toolkit were available, would you use it as part of your studies?"
Yes 85
No 0
Don't Know 15
Q15. Learning using the toolkit is more effective compared to learning from a description or reading a book on the topic.
Strongly Agree 8
Agree 69
Neutral 15
Disagree 8
Strongly Disagree 0
Q16. Learning using the toolkit is more effective compared to learning in a lecturing/tutorial environment.
Strongly Agree 23
Agree 69
Neutral 8
Disagree 0
Strongly Disagree 0
Q17. Learning from the toolkit is more effective compared to learning from a simulation.
Strongly Agree 8
Agree 38
116 Neutral 46
Disagree 8
Strongly Disagree 0
"Q18. With the aid of the toolkit, how would you rate your ability in designing solutions for concurrency issues?"
Improved 100
Disimproved 0
Same as previously 0
Q19. The toolkit made appropriate use of the handheld devices to support the tasks.
Strongly Agree 38
Agree 54
Neutral 8
Disagree 0
Strongly Disagree 0
Q20. How would you rate the usefulness of being able to simulate and manage a multi-process environment?
Excellent 38
Very Good 46
Good 15
Fair 0
Poor 0
Q21. Did you enjoy the experience of using the toolkit?
Yes 100
117 No 0
Indifferent 0
Q22. The classic problems presented were appropriate descriptions of concurrency mechanisms.
Strongly Agree 31
Agree 69
Neutral 0
Disagree 0
Strongly Disagree 0
Q23. The toolkit was easy to use.
Strongly Agree 15
Agree 69
Neutral 15
Disagree 0
Strongly Disagree 0
Q24. Did you learn from the experience of using the toolkit?
Yes 100
No 0
Don't Know 0
Q25. I feel more motivated to learn when using the toolkit compared to other experiences with learning concurrency.
Strongly Agree 23
Agree 62
118 Neutral 15
Disagree 0
Strongly Disagree 0
Q26. Using the toolkit supported me in learning from my colleagues.
Strongly Agree 46
Agree 46
Neutral 8
Disagree 0
Strongly Disagree 0
119 REFERENCES
Anderson, T. (2002). An Updated and Theoretical Rationale for Interaction., IT Forum. 2004 .
Andrews, G., & Olsson, R. (1993). The SR Programming Language: Concurrency in Practice , Benjamin-Cummings.
Andrews, G., R. (1991). Concurrent programming: principles and practice . Redwood City, CA, Benjamin-Cummings Publishing Co. Arnedillo Sánchez, I., Savage, T., & Tangney, B. (2004). Higher Education (HE), Information Communication Technology (ICT) and Learning: ICT for replication OR innovation? AISHE Conference, Dublin. Bacon, J. (1998). Concurrent Systems: Operating Systems, Database and Distributed Systems: An Integrated Approach , Addison-Wesley. Ben-Ari, M. (1990). Principles of Concurrent Programming , Prentice Hall. Benford, S., Rowland, D., Flintham, M., Hull, R., Reid, J., Morrison, J., Facer, K. & Clayton, B. (2004). "Savannah": Designing a Location-Based Game Simulating Lion Behaviour . International Conference on Advances in Computer Entertainment Technology. Bransford, J., Sherwood,R., Hasslebring, T., Kinzer, C. & Williams, S. (1990). Anchored Instruction: Why We Need It and How Technology Can Help. Cognition, Education and Multimedia: Exploring Ideas in High Technology . D. a. S. Nix, R., Lawrence Erlbaum Associates Inc. Brewster, S. (2002). "Overcoming the Lack of Screen Space on Mobile Computers." Personal and Ubiquitous Computing 6: 188-205.
Brown, J. S., Collins, A., & Duguid, S. (1989). "Situated cognition and the culture of learning." Educational researcher 18 (1).
Bruner, J. (1966). Towards a Theory of Instruction . Cambridge, Harvard University Press. Bruner, J. S. (1966). Toward a theory of instruction . Cambridge, Havard University Press. Bull, G., Bull, G., Garofalo, J., & Harris, J. (2002). "Grand Challenges: Preparing for the Technological Tipping Point." Learning & Leading with Technology 29 (8).
Churchill, E., Snowdon, D., & Munro, A. (2001). Collaborative virtual learning environments, digital places and spaces for interaction. London, Springer-
120 Verlag. Coffman, E., G., Elphick, N., J., Shoshani, A. (1971). "System Deadlocks." Computing Surveys 3(2).
Cole, H., & Stanton, D (2003). "Designing mobile technologies to support co-present collaboration." Pers Ubiquit Comput (7).
Costelloe, E. (2004). The Use of a Software Enabled Scaffolding Environment to Aid Novice Programmers Computer Science . Dublin, Trinity College. M.Sc: 156.
Crippen, K., & Brooks, DW. (2000). "Using personal digital assistants in clinical supervision of student teachers." Journal of Science Education and Technology 9(3).
Danesh, A., Inkpen, KM, Lau, F, Shu, K., & Booth, KS (2001). Geney: Designing a collaborative activity for the Palm handheld computer. Conference on Human Factors in Computing Systems. Dijkstra, E., W., (1965). "Cooperating Sequential Processes." EWD123 .
Dillenbourg, P. (1999). What do you mean by collaborative learning? Collaborative Learning: Cognitive and computation approaches . P. Dillenbourg. Oxford, Elsevier. Downey, A. (2005). Little Book of Semaphores . Boston, Green Tea Press. Engel, E. (1991). Not just a method but a way of learning . London, Kogan. Falk, J. H., & Dierking, L.D. (2000). Learning from museums: Visitor experiences and the making of meaning , Altamira. Feldman, M., B., Lopes, A.,V., Perez, M. (1990). SMALL-Ada: personal computer courseware for studying concurrent programming . Technical Symposium on Computer Science Education, Washington, D.C. Ferguson, D. (2001). "Technology in a constructivist classroom." Information Technology in Childhood Education Annual : 45-55. Gage, N., L., Berliner, D.C. (1992). Educational Psychology . Boston, Houghton Miffin. Gay, G., Rieger, R., & Bennington, T. (2002). Using mobile computing to enhance field study. CSCL 2: carrying forward the conversation . R. H. N. a. M. T Koschmann, Lawrence Erlbaum Associates Inc. Heidegger, M. (1962). Being and Time , Blackwell
Henderson, P. B. (1986). "Anatomy of an introductory Computer Science Course." Proceedings of the Seventeenth SIGCSE technical symposium on Computer
121 Science Education: 257-263. Honebein, P. (1996). Seven goals for the design of constructivist learning environments. Constructivist learning environments: Case studies in instructional design . B. Wilson. New Jersey, Educational Technology Publications : 11-24.
Horton, B., & Wiegert, E. (2002). "Using handhelds and billiards to teach reflection." Learning & Leading With Technology 29 (8).
IEEE., A. (2001). Computing Curricula. The Joint Task Force on Computing Curricula. , IEEE Computer Society & Association for Computing Machinery. Inkpen, K. (1999). "Designing Handheld Technologies for Kids." Personal Technologies 3(1): 81-89.
Innovation, T. I. f. L. (2002). Contextual Model of Learning Jenkins, T. (2001). "Teaching Programming – A Journey from Teacher to Motivator." First LTSN-ICS Conference on Teaching Programming .
Jonassen, D. (1998). Constructivist learning environment on the web, engaging students in Meaningful Learning. Kurtz, B., Kim, C., & Alsabbagh, J. (1998). Parallel Computing in the Undergraduate Curriculum . SIGCSE Lamport, L. (1994). "Introduction to TLA." SRC Technical Note . Linder, S., P., Nestrick, B., E., Mulders, S., Lavalle, C., L. (2001). "Facilitating Active learning with inexpensive Mobile Robots." The Journal of Computing in small colleges 16 (4).
Luff, P., Heath, C. (1998). Mobility in collaboration . Computer Supported Collaborative Work, Seattle, Washington. Magee, K., Kramer, J. (2000). Concurrency: State Models & Java Programs . Chichester, Wiley & Sons. McGreen, N., & Arnedillo Sánchez, I. (2005). Mobile Phones: Creative Learning Tools . Mobile Learning, Malta, International Association for Development of the Information Society Press Michie, M. (1998). "Factors influencing secondary science teachers to organise and conduct field trips." Australian Science Teacher's Journal 44 (4).
Naismith, L., Lonsdale, P., Vavoula, G., & Sharples, M. (2005). Literature Review in Mobile Technologies and Learning, NESTA Futurelab Series. Papert, S. (1991). Situating Constructionism. Constructionism . I. P. Harel, S. .
122 Norwood, NJ, Ablex Publishing. Papert, S. (1993). The Children's Machine: Rethinking School in the Age of the Computer , Basic Books. Patten, B., Arnedillo Sánchez, I., Tangney, B. (2005). "Designing collaborative, constructionist and contextual applications for handheld devices." Computers & Education (Special CAL05 Issue). Piaget, J. (1970). Piaget's theory. Handbook of child psychology . P. Mussen. New York, Wiley. Pownell, D., & Bailey, G. D. (2000). "The next small thing: handheld computing for educational leaders." Learning and Leading with Technology 27 (8).
Price, B. A., Baecker, R. M., Small, I. S., (1993). "A Principled Taxonomy of Software Visualization." Journal of Visual Languages and Computing 4(2): 211-266.
Rieger, R., Gay, G. (1997). Using mobile computing to enhance field study. ACM- Computer Support for Collaborative Learning, University of Toronto, Toronto, Canada. Riley, D. (1981). "Teaching problem solving in an introductory computer science class." 12th SIGCSE Technical Symposium on Computer Science Education . Robertson, S., Calder, J., Fung, P., Jones, A., & O'Shea, T. (1997). "The use and effectiveness of palmtop computers in education." British Journal of Educational Technology 28 (3).
Roman, G.-C., Cox, K. C. (1993). "A Taxonomy of Program Visualization Systems." IEEE Computer 26 (12): 11-24.
Roschelle, J. (2003). "Unlocking the learning value of wireless mobile devices." Journal of Computer Assisted Learning 19 (3).
Roschelle, J., & Teasley, S. (1995). Construction of shared knowledge in collaborative problem solving , Springer-Verlag. Roth, J. (2000). "DreamTeam - A Platform for Synchronous Collaborative Applications." AI & Society 14 (1): 98-119.
Savery, J. D., T. (1996). Problem-based learning: An instructional model and its constructivist framework. Constructivist learning environments: Case studies in instructional design B. Wilson. New Jersey, Educational Technology Publications. : 135-148.
Sharples, M. (2000). "The Design of Personal Mobile Technologies for Lifelong Learning." Computers & Education (34): 177-193.
123 Smith, B., & Blankinship, E. (2000). "Justifying imagery: Multimedia support for learning through explanation." IBM Systems Journal 39 (3).
Smordal, O., & Gregory, J. (2003). "Personal Digital Assistants in medical education and practice." Journal of Computer Assisted Learning 19 (3).
Soloway, E., Norris, C., Blumenfeld, P., Fishman, B., Krajcik, J., & Marx, R (2001). "Log On Education: Handheld Devices are Ready-at-Hand." Communications of the ACM 44 (6).
Soloway, E., Norris, C., Blumenfeld,P., Fishman, B., Krajcik, J., & Marx, R. (2001). "Devices are Ready-at-Hand." Communications of the ACM 44 (6): 15-20.
Stallings, W. (2000). Operating Systems: Internals and Design Principles , Prentice Hall. Stanton Fraser, D., Smith, H., Tallyn, E., Kirk, D., Benford, S., Rowland, D., Paxton, M., Price, S., & Fitzpatrick, G. (2005). The SENSE project: a context-inclusive approach to studying environmental science within and across schools . CSCL. Tanenbaum, A., Woodhull, A. (1997). Operating Systems: Design and Implementation . New Jersey, Prentice Hall. Tinker, R. (1997). The whole world in their hands, Concord Consortium. Traxler, J. (1994). Teaching Programming Languages and Paradigms . Second All Ireland Conference on Curriculum and Computing, Dublin. Vosniadou, S. (1994). "Capturing and modeling the process of conceptual change." Learning and Instruction 4: 45-69.
Vygotsky, L. (1978). Mind in Society: The Development of Higher Psychological Processes. Cambridge, Harvard University Press. Wiggins, R. (2004). "Personal Digital Assistants." Journal of Digital Imaging 17 (1): 5- 17. Yurcik, W., & Osborne., H. (2001). A Crowd of Little Man Computers: Virtual Computer Simulator Teaching Tools . Winter Simulation Conference. Zurita, G., & Nussbaum, M (2004). "A constructivist mobile learning environment supported by a wireless handheld network." Journal of Computer Assisted Learning 20 (4).
Zurita, G., Nussbaum, M., & Sharples, M. (2003). Encouraging face-to-face collaborative learning through the use of handheld computers in the classroom. Mobile HCI 2003, Berlin, Heidelberg, Springer-Verlag.
124