Practical Case Studies in Teaching Concurrency. A. J. Cowling

Transcription

1 Practical Case Studies in Teaching Concurrency A. J. Cowling Department of Computer Science, University of Sheffield, Sheffield, S10 2TN, UK. Telephone: ; Fax: ; As with all aspects of computing, there are four main strands to teaching concurrency, viz hardware, theory, applications and programming, with programming linking the other three together. The basic requirements for practical work for each of these strands are discussed, and the problems of meeting these requirements. These have usually limited practical work in concurrency either to theoretical exercises, or to simple programming assignments in which students build complete programs starting from some given specification. The aim of this paper is to present some examples of an alternative approach to practical work in concurrency, using case studies instead of expecting students to build complete systems for themselves. Features and benefits of the case study approach are described, and examples are given of three case studies that have been used successfully. Finally, the role of software tools in facilitating such case studies is discussed briefly. Introduction The work presented here has been developed largely within the framework of a set of courses that aim to teach both computer science and software engineering. Consequently, they have to give students an understanding of the basic scientific concepts involved and the models that can be used to analyse them, and also give them an understanding of the engineering aspects of how these concepts are applied in practice and of how to design systems that utilise them. To help produce courses that meet this dual aim, we have found it helpful to structure the subject area into four broad strands, viz hardware, theory, applications and programming, of which programming is the one that links the other three together, as illustrated in figure 1. Applying this to parallel processing, the hardware strand covers all aspects of parallel system architecture, and in our case particularly transputer architecture, while the theory strand covers basic concepts such as processes, mutual exclusion and synchronisation as well as models of concurrency like CSP [1] and CCS [2]. In considering applications of concurrency, we focus primarily on operating systems, communications systems, databases and specialised machine architectures. Then, the programming strand covers not only occam [3] and its channel-based model of process communication, but also the shared variable model that is provided in our case by the parallel processing facilities defined [4] for Modula- 2.

2 Applications Programming Hardware Theory Figure 1: The Four Strands of Computing. For the theory and programming strands students can learn a lot from simple practical exercises, such as analysing very basic models in CCS or CSP, or writing short programs when learning a concurrent language. The nature of concurrency, however, means that even quite simple examples can be complex to analyse, and so for CCS models we have experimented with using the Concurrency Workbench [5], which enables students to investigate larger examples than they could do by hand. For instance, the CCS model of Decker's Algorithm [6] involves five parallel agents defined in terms of sixteen agent expressions, so that expecting students to prove mutual exclusion or liveness by hand would be unrealistic. The Workbench makes it feasible for them to examine such examples, although its user interface has not proved very friendly: in particular, students have found it difficult to extract output that enables them to visualise easily the action trees generated by the agents. For the hardware and applications strands there is the same need for exercises to be complex enough to be realistic, so that the simple approach of asking students to write a complete program starting from a clean sheet does not work well. Concurrent systems usually need to be well designed to work at all, but students do not have the experience to design them well, so that if they are just asked to write a complete program of any significant size there are far too many opportunities for them to produce bad designs. The solution that we propose to this problem is to build case studies, in which the students are given material developed by the instructor, and then asked to investigate its behaviour, and to modify or extend it in ways that will illustrate the particular points that are important for that case study. The advantage of this approach is that the given software can be large enough to represent realistic 2

3 applications of concurrency, and designed to a known quality, but without the students having had to spend the time needed to develop it. To illustrate this, we consider three such case studies that have been developed at Sheffield, and show how they demonstrate these advantages in practice. Client-Server Architectures This study has been developed as a Modula-2 program, that uses the concurrency facilities of the standard module Processes to illustrate client and server processes communicating through a queue of request blocks, as in the device handlers of an operating system. This structure is illustrated in figure 2, and it is presented as though the server is a disk driver, and the clients are processes wishing to have blocks transferred to the disk, so that a client has to find a free block in the queue, and fill it up with the details of its request. The driver then takes blocks from the queue and processes the requests, while the client has to wait until the driver has finished dealing with its request, when it can clear the block ready for re-use. Client1 Queue Blocks Server Client2 MakeRequest WaitUntilDone ClearRequest GetRequest GetData, etc FinishRequest Figure 2: The Client - Server Structure Case Study. As presented there are three concurrent processes (two clients and one driver), and the queue is set up to contain three request blocks, so that there are more blocks available than required. This eliminates one need for synchronisation, which is important as the code contains no mutual exclusion and only minimal synchronisation. Therefore, the client includes an operation to check that the request was actually carried out properly, as this version of the system can not be guaranteed to work correctly. Where synchronisation is provided it is by active wait loops, which can be implemented easily using the standard procedure Reschedule to avoid livelock. This could tempt students to produce solutions that depend on controlling the scheduling in some way, and so to avoid this a separate module has been provided that exports a procedure Randomise which is used instead. This 3

4 uses a crude congruential random number generator to determine whether or not to invoke Reschedule, and so makes the scheduling appear non-deterministic. Students are then told not to interfere with the operation of either this or some of the other low-level modules, such as the one that outputs trace information to the screen. Within this framework the students can then be asked to make a number of improvements to the system, of which the most basic is to locate the concurrent updating problem that can occur when clients try to simultaneously claim the same block of the queue, and then to insert semaphores to provide the mutual exclusion necessary to solve this problem. Experience suggests that although this exercise sounds simple, the fact that a realistic amount of code has to be investigated means that it actually gives the students a very good understanding of how such problems can occur in practice, and can be solved. Other basic problems that can be set are to insert suitable semaphore synchronisation where required, for example to replace the active wait loops. Some of these are straightforward, but others involve a significant design element, such as the case of a client waiting until the driver has processed its request, in which there are several alternatives for the point where the semaphores are created and the way in which they are associated with the request blocks. The most elaborate exercise that we have used with this case study relies on the fact that both synchronisation and mutual exclusion are achieved with semaphores, and so problems of deadlock can be made to occur if semaphore operations are not correctly ordered. To illustrate this, the operation for releasing a request block has to become a critical section as well as the operation of claiming a block, and the same semaphore has to be used for both critical sections. The students can then be asked to consider the effect of locating the synchronisation operations that control waiting for free request blocks either inside or outside the relevant critical sections. They can also be asked to consider how the problem could be overcome, apart from reordering semaphore operations, and so can see how the constructions would operate that could be used to solve these problems within monitors, although this study can not actually use monitors because Modula-2 does not support the concept. Communication Protocols This study has also been developed as a Modula-2 program, but here the concurrency comes not from concurrency within processes running on one machine, but from the one program running simultaneously on two separate networked PCs, and communicating over the network. The basis of the study is a pair of modules that give access to some of the facilities of the standard NetBios [7]: a low level one to give a full NetBios interface, and a higher level one providing functions that allow individual machines to set up simple numeric addresses to identify themselves, and to send and receive single packets through the network. This structure is illustrated in figure 3. 4

5 Sender RxTx NbComms NetBios NetBios Program for Case Study Modula2 Library Modules Underlying Network Receiver RxTx NbComms NetBios NetBios Figure 3: The Structure of the Communication Protocol Software. As used at present, this study aims to help students understand how conventional link-level protocols use acknowledgements to provide reliable synchronised communication of complete messages, and to understand how these protocols can be defined by communicating finite-state machines. It therefore consists of a single program, using these two modules, that operates as either end of a unidirectional link, so that when run on two machines one is made to act as transmitter and the other as receiver. Each one determines and displays the address of the machine that it is running on, and waits for the operator to input the receiver address to the transmitter and vice-versa. To allow them then to synchronise, at least to within the limits of the timeouts used for the receive operations (typically 7 to 10 seconds) they then each wait for a further key press before first trying to send or receive. In its present form the study is normally used with the ISO Basic Mode protocol [8], since this is about the simplest link-level protocol, but it could also be used with a more complex protocol such as HDLC [9]. An important part of the exercise has been that the students should derive the transition and output tables for the finite state machines. Previously they have also then been expected to design appropriate representations of these, and to construct the code to implement the machines using these representations, but this has resulted in too much time being spent on details of the coding, and not enough time on the operation of the protocols being studied. As such, this example illustrates very well the advantages of the case study approach, for if the tables are represented as arrays then it would be quite possible to give the students most of this representation, and also the code that uses it to implement the machines. If this were done then all that the students would need to do as the first stage of the study would be to complete the representations, and initialise the tables to match the ones that they had derived on paper. As a 5

6 second stage they could then experiment with the protocols, for instance to see how Basic Mode would need to be modified if frames were numbered rather than acknowledgements. Of course, for such experiments to be feasible it needs to be possible to test the protocol thoroughly, and with the present version of the case study we have found that this is actually a major problem in practice, since the underlying network is so reliable that packets just do not get corrupted. While this is an advantage in one respect, as it means that students do not have to waste time attempting to incorporate any form of redundancy checking into their protocols, it is outweighed by the difficulties that it causes for testing. In the next version of this study, therefore, we propose to incorporate into the underlying packet transfer mechanism a code within each packet that can be set by the transmitter to indicate that the receiver is to treat the packet as invalid, and will adopt from the client-server study the technique of using a simple random number generator to control part of the operation of the system. In this case, the random numbers will determine which packets are to be rejected, although we shall need to allow the average rate of reject packets to be controlled, particularly so that it can be set to zero for the early stages of any testing, when the emphasis will be on ensuring that the normal exchange of valid packets operates correctly. Embedded Systems Demonstrator This case study differs from the others in that it involves special hardware as well as software, and also it was originally designed to be studied by practicing engineers rather than students, to show how transputer-based equipment could be utilised effectively within embedded systems. It was developed initially by Kerridge, and much of the hardware design carried out by Thompson [10], and the basic software case study was presented by Kerridge at Transputing 91 in Santa Clara. As illustrated in figure 4, the hardware consists of a single board carrying a T222 transputer, a CO11 link adapter connected to one of its links, some memory (RAM and ROM), a variety of interfaces and peripherals and a power supply. The interfaces are typical of those that might be needed for embedded systems: two parallel adapters, a DUART, an A-D and a D-A convertor, and also some custom logic to generate event signals to the transputer from the interrupt request signals from the interfaces. Both the registers in the custom logic and the interface registers are mapped into the external memory space. The peripherals consist of a meter to display the analogue output, a 12- button keypad, a 4-digit 7-segment display, eight toggle switches and eight LED lamps; they can be connected to the link adaptor or other interfaces in appropriate configurations via plugs and sockets on the board. The other three transputer links can be used to connect to an external host or to other 6

7 similar boards, so that software can be downloaded onto the board from a development system, and this allows the board to be used for a variety of applications. To other systems To Host T222 Link Adaptor Keypad 7-segment Display Buses PPI Events Event Generator Logic PIA DUART 2 x 25 8 switches 8 lamps 32k RAM 32k ROM A to D BNC D to A BNC Meter Figure 4: The Embedded Systems Demonstrator Hardware. For this particular case study the aim is to produce a system that simulates the operation of a photocopier: the keypad is used to input the number of copies required and to provide the start and cancel functions; the display is used to show the number of copies still to be made; the output from the D-A convertor is used to represent the paper moving through the copier unit; the switches are used to simulate various fault conditions, such as jam or paper out; and the lights are used as fault and ready indicators, and to show when various components are operating, such as the heater, the copying lamp and the input and output paper feed motors. This needs three interfaces to be used: for the D-A convertor, a parallel one for the lamps and switches, and the other parallel one for the keypad and display. The occam software that is provided for the study consists of a skeleton for the main controller process, plus a set of three complete processes, one to handle each of the peripheral interfaces in a polling mode. Each of these processes communicates with the main controller process through a set of channels, whose protocols allow the controller to send commands for output and read data values that have been input. Thus, the study consists mainly of building up the controller in stages, initially to provide the basic functions of simulating paper movement for single and then multiple copies, and then to add the other features such as responding to fault conditions. It could then be extended further, as sets of processes have been built to provide drivers for each of the interfaces that use interrupt service routines (with various degrees of buffering of data) rather than polling, and so it would be possible to experiment with using these in place of the current drivers. 7

8 Conclusions Our experience of these case studies has been that they offer significant advantages over the approach of requiring students to develop complete programs starting from a clean sheet. The students save a lot of time that would otherwise have to be spent developing the basic code that they are given in the case studies (at least 300 lines of source in each of our examples). At the same time, they gain experience in reading and understanding code that has been produced by others, and these skills are almost as valuable to them as those of designing and writing their own programs. Also, because they have been given this code rather than having to develop it themselves the experiments that they are asked to do start from a base with known characteristics and quality. These advantages would apply to teaching any aspect of computing, but the approach has a particular advantage for teaching concurrency, where one wants students to be able to concentrate on the important aspects of the parallelism and how it is used. The case study approach supports this by allowing basic sequential aspects to be dealt with in the prepared material, so that the studies (and the students) can focus on the concurrent processes and how they interact. For these reasons we have found this approach beneficial, and we hope that our experience will encourage others to try it too. References 1. C. A. R. Hoare, Communicating Sequential Processes, Prentice Hall, R. Milner, Communication and Concurrency, Prentice Hall, INMOS Ltd, occam 2 Reference Manual, Prentice Hall, N. Wirth, Programming in Modula-2, Springer-Verlag, (4th edition) R. Cleaveland, J. Parrow & B. Steffen, The Concurrency Workbench, Proc. Workshop on Automated Verification Methods for Finite-State Systems, LNCS 407 pp 24-37, Springer- Verlag, D. J. Walker, Automated Analysis of mutual exclusion algorithms, Formal Aspects of Computing 1.3 pp (1989). 7. W. D. Schwaderer, C Programmer's Guide to NetBios, Howard Sams, ISO Standard 1745 (1975), Basic Mode Control Procedures for Data Communication Systems. 9. ISO Standard 4335 (1991), HDLC - Consolidation of Elements of Procedures. 10. J. A. Thompson, Transputer and Embedded Systems Evaluation Board - User and Technical Manual, National Transputer Support Centre, Sheffield (1990). 8