MODELLING AND VERIFICATION OF CONCURRENT PROGRAMS USING UPPAAL Franco Cicirelli, Libero Nigro, Francesco Pupo Laboratorio di Ingegneria del Software Dipartimento di Elettronica Informatica e Sistemistica Università della Calabria 87036 Rende (CS) – Italy Email: [email protected], {l.nigro,f.pupo}@unical.it KEYWORDS network of timed automata (Alur and Dill, 1994), to Modelling and verification, simulation, concurrency, animate it in simulation to check qualitative behaviour mutual exclusion, synchronizers, timed automata, thus making a preliminary debug, and to prove UPPAAL, Java. (provided the model is not too large) functional/temporal properties of the system at hand ABSTRACT through model checking (Clarke et al., 2000)(Cicirelli et al., 2007)(Cicirelli et al., 2009)(Furfaro and Nigro, This paper describes the design and implementation of a 2007). The approach is similar but independent and library of reusable UPPAAL template processes which original with respect to that described in (Hamber and support reasoning and property checking of concurrent Vaandrager, 2008). A key factor of the work described programs, e.g. to be realized in the Java programming in this paper concerns the development of concurrent language. The stimulus to the development of the structures and synchronizers which are inspired by the library originated in the context of a systems concurrent package of the Java programming language. programming undergraduate course. The library, The UPPAAL toolbox was chosen because it is popular, though, can be of help to general practitioners of it is continually improved and it is efficient (in space concurrent programming which nowadays are and time) in the handling of large model state graphs. challenged to exploiting the potentials of modern multi- Moreover, the toolbox offers a friendly graphical user core architectures. The paper describes the library and interface which facilitates reasoning upon model demonstrates its usage to modelling and exhaustive behaviour. verification of mutual exclusion and common This paper describes (part of) the developed library and concurrent structures and synchronizers. UPPAAL was demonstrates its usefulness by studying mutual chosen because it is a popular and continually improved exclusion algorithms and by showing some common toolbox based on timed automata and model checking concurrent synchronizers which are available in the and it is provided of a user-friendly graphical interface Java programming language. Concurrent models are which proves very important for debugging and then applied to a sample problem. The approach makes property assessment of concurrent models. Java was it simple to transform a concurrent solution model into a considered as target implementation language because corresponding Java implementation. The solutions, of its diffusion among application developers. though, can be ported to other languages as well. Finally, conclusions are drawn with an indication of INTRODUCTION further work. Current technological trend on multi-core machines MUTUAL EXCLUSION ALGORITHMS challenges developers to exploit concurrency in general purpose applications which can have a performance Concurrent processes accessing shared data require two gain from the computational parallelism offered by kinds of mechanisms (see e.g. (Stallings, modern personal computers. However, as students and 2005)(Silberschatz et al., 2010)): mutual exclusion developers know, concurrent programs are hard to which guarantees only one process at a time can enter design and difficult to debug. Common experimented its critical section, and synchronization, i.e. the problems include race conditions, deadlocks and possibility for a process in a critical section to suspend starvation (Stallings, 2005)(Silberschatz et al, 2010). its execution when the data values do not permit the Motivated by the desire to help students of a systems process to complete its operations. In this section the programming undergraduate course to have a more focus is on mutual exclusion based on busy-waiting by critical approach to concurrent programming, authors “pure software” solutions (other solutions can be based have designed and prototyped a reausable library of on the hardware support, e.g. test and set instructions or UPPAAL (Bengtsson and Yi, 2003)(Behrmann et al., the interrupt system). Such mutual exclusion algorithms 2004) template processes. The library enables a are normally discussed in a systems programming concurrent solution to be formally modelled as a course for introducing students to race conditions and Proceedings 25th European Conference on Modelling and Simulation ©ECMS Tadeusz Burczynski, Joanna Kolodziej Aleksander Byrski, Marco Carvalho (Editors) ISBN: 978-0-9564944-2-9 / ISBN: 978-0-9564944-3-6 (CD) interference problems among concurrent processes. In which every single instruction is modeled and timed the following, algorithms for N>2 processes are (e.g. each instruction consumes 1 time unit) is instead considered. Examples include the Bakery algorithm and advocated in (Hamber and Vaandrager, 2008). Fig. 2 the Eisenberg and McGuire algorithm ((Silberschatz et shows the proposed UPPAAL model for the generic al., 2010) page 302). Fig. 1 shows a pseudo code of the Process of Eisenberg and McGuire algorithm. Duration generic process according to the Eisenberg and of the critical section is supposed to be in the [2,6] time McGuire algorithm. interval. The template Process receives its unique id i as parameter. //shared variables used by the algorithm The use of committed locations mirrors the assumption enum pState {idle, want_in, in_cs} that instructions executed during the entry/exit part are pState flag[n]; //all elements initialized to idle supposed to be time negligible with respect to the int[0,n-1] turn; //no particular initialization critical section duration. Of particular concern is the //ith process realization of the busy-waiting during the enter part. int[0,n] j; do{ //enter part The process enters the Busy_Wait location from which while(true){ it exits at each change of shared variables. To this flag[i]=want_in; //I want to enter my critical section purpose a broadcast channel check is used. The process j=turn; //give priority to non idle processes, if there which enters or exits from its critical section forces all //are any, from turn to i clockwise processes in busy waiting to reconsider their situation. while(j!=i){ //busy waiting The following global UPPAAL declarations were used: if( flag[j]!=idle ) j=turn; else j=(j+1)%n; const int N=5; //number of processes } typedef int[0,N-1] pid; //process identifier subtype flag[i]=in_cs; //I "enter" my cs typedef int[0,2] pState; j=0; broadcast chan check; //it there exists in the entire ring a const int idle=0; //process with in_cs status ? const int want_in=1; while( (j<n) && (j==i ||flag[j]!=in_cs) ) j++; const int in_cs=2; if( (j>=n) && (turn==i || flag[turn]==idle) ) pid turn; /*no*/ break; pState flag[N]={idle,idle,idle,idle,idle}; //yes, waits clock x[N]; //process clocks } clock y[N]; //decoration clocks turn=i; //its my turn //critical_section The system declaration section consists only of: //exit part //starting from me (turn==i) //search the first not idle process system Process; j=(turn+1)%n; while( flag[j]==idle ) j=(j+1)%n; which ensures, due to the pid parameter of the Process turn=j; //give it its turn template, that N instances of the template are created to flag[i]=idle; populate the model. These instances have names //non_critical_section Process(0), ..., Process(N-1). }while(true) Table 1 shows the queries used to verify the mutual Figure 1. Eisenberg and McGuire mutual exclusion exclusion algorithm. Query 1 verifies the absence of algorithm for N processes deadlocks. Queries 2 and 3 check, with different syntax, the fundamental mutual exclusion property: no more Now the goal is to model in UPPAAL the algorithm in than one process can find itself into the critical section. Fig. 1 and proving it fulfils all the three basic Queries 4 and 5 respectively determine minimal and properties: (a) only one process at a time can enter its maximal delay when waiting for entering the critical critical section, (b) a process waiting for entering its section. Query 4 is not satisfied if a value greater than 0 critical section would not delay infinitely (absence of is used. Query 5 is not satisfied if a value lesser than 24 starvation), (c) no assumption is made about the relative is used. Decoration clocks y[i] are reset when a process speed of the processes. The modelling strategy starts the enter part of the protocol and measure the purposely allows to concentrate on the essential of the elapsed time of waiting. Obviously, queries 4 and 5 algorithm while ensuring a certain efficiency of the have the same conclusion for any process i. It is model checking. The model abstracts away the duration guaranteed that the waiting time is bounded and of the single instructions carried out during the entry amounts as upper bound to (N-1) critical sections. section and the exit section of the protocol, thus making Queries 6 and 7 check progress properties. In particular, it possible to determine the delay time of a process query 6 guarantees that a process which starts the enter waiting to enter its critical section, in terms of the part of the protocol, eventually enters the critical section number and duration of critical sections executed by (this is of course also confirmed by bounded waiting other processes. The “high resolution” approach, in time). Similarly, query 7 says that a process which starts the enter part of the protocol always comes back to be self-explanatory. This algorithm too ensures a home (Non_CS location). bounded waiting time of at most (N-1) critical sections. Table 1 CATALOG OF REUSABLE CONCURRENT Query Result MODELS 1 A[] !deadlock satisfied E<> Process(0).In_CS+Process(1).In_CS+ Mutual exclusion algorithms like those shown in the not 2 Process(2).In_CS+Process(3).In_CS+ previous section can be the basis for implementing high satisfied Process(4).In_CS>1 level concurrent structures.