A Spin-based model checking for the simple concurrent program on a preemptive RTOS
AA Spin-based model checking for the simple concurrentprogram on a preemptive RTOS
Chen-Kai Lin
Institute of Information Science,Academia SinicaTaipei, [email protected]
Ching-Chun (Jim) Huang
Department of Computer Science andInformation Engineering, NCKUTainan, [email protected]
Bow-Yaw Wang
Institute of Information Science,Academia SinicaTaipei, [email protected]
ABSTRACT
We adapt an existing preemptive scheduling model of RTOS ker-nel by eChronos from machine-assisted proof to Spin-based modelchecker. The model we constructed can be automatically verifiedrather than formulating proofs by hand. Moreover, we look into thedesigns of a Linux-like real-time kernel–Piko/RT and the specifica-tion of ARMv7-M architecture to reconstruct the model, and useLTL to specify a simple concurrent programs–consumer/producerproblem during the development stage of the kernel. We show thatunder the preemptive scheduling and the mechanism of ARMv7-M,the program will not suffer from race condition, starvation, anddeadlock.
KEYWORDS model checking, concurrent program, preemptive scheduling
Model checking [6, 7] is first introduced by Edmund Clarke andAllen Emerson in 1981 to solve the Concurrent Program Verifica-tion. It has a state-transition graph (denote as a model) and somelogic formulas (denote as properties). The algorithm of model check-ing will try to claim that all paths of the model are satisfied theproperties. In other words, if we write a property about mutualexclusion and the model checker says the property is unsatisfied,we can trace the error messages back to the situation and inspectwhether the model or the real-world system will suffer from therace condition.Concurrent errors are hard to detect by code review or testcase, because we can not guarantee the asynchronous processesexecuting in a specific order. Another way to ensure the correctnessof concurrent programs is by proof, one example is that Lamportproves the correctness of a fast mutual exclusion algorithm in1987 [15]. But, this strong guarantee requires the preliminary ofproof tactic and constructs by hands. Model checking, though, hasweaker guarantee but is more expeditious only if the abstract modeland the real-world system are homogeneous. Furthermore, thecorrectness of the algorithm can not stand for the correctness ofthe implementation on other hardware or software mechanisms,i.e. interrupt or softirq. Holzmann [10] indicates model checkingis one of the three topics that the Mars Science Laboratory (MSL,launched by NASA) has used to reduce risk in complex softwaresystems. He also points out that they had successfully verified several concurrent issues on key parts of the spacecraft, includingCassini, Deep Space One, and the Mars Exploration rovers.Piko/RT [12], developed at National Cheng Kung University, isa non-trivial operating system but small enough for verificationpurpose. One of the key features is real-time capability. It enablesinterrupts (exceptions) almost all the executing time to handle theincoming IRQs. Moreover, it is optimized for the ARM Cortex-Mseries. Until 2015 [5], ARM had shipped 20.6 billion Cortex-M unitswithin six years and the number is growing. It is hard to debug ifsuch a number of devices deployed around in different areas. Notto mention the software system must not behave unexpectedly inthe critical usages.In this paper, we address the problem of verifying the simpleconcurrent programs will not act unexpectedly (no race condition,starvation, and deadlock) under the specific conditions (preemptivescheduling and interrupt-driven mechanisms). We first construct anabstract model on the Spin model checker based on three domains:proof framework of eChronos, source code of Piko/RT, and refer-ence manual of ARMv7-M, discussing in section 3. Next, write threeproperties (race condition free, starvation free, and deadlock free)and verify in Spin (section 4 and 5). Last but not least, discuss thebackground knowledge and summarize the conclusions in section2 and 6. All our model is in the public domain. We use Spin as our model checking tool and build an abstract sched-uling model on. In this section, we discuss some topics about Spinmodel checker and the real-time scheduling before approaching tothe model. And then, talk about several related works of this paper.
Spin [3, 9, 11] is an open-source verification tool ofmulti-threaded software developed in the Computing Science Re-search group of Bell Lab. The theory behind Spin is the ω -automaton,which is the variation of classic finite state automata with accep-tance conditions on infinite executions. Consider Figure 1a, notethat the termination of the automata would not necessarily be adesirable result. We can declare some state that will be visited infin-itely often by labeling accept , i.e. Run state, as a legal run. Becausethe states are finite, the infinite run ( ω -run) will anyway repeatitself at the certain degree just like Figure 1b shows. If Spin find an ω -run with some state labeling accept , it can claim that the automatais accepted. This is so called the Büchi acceptance. https://github.com/kaizsv/pikoRT-Spin.git a r X i v : . [ c s . O S ] A ug (a) Finite state infinite run au-tomata. (b) A path of ω -run Figure 1: Example of ω -automatonFigure 2: Semantics of Global and Future operators Every thread in Spin is an automata and product altogether inthe verifying stage. Spin supports a meta language: PROMELA,which interpreting readable script into automata, like commoncondition statements, if or do . It also provides channel allowingthe communication between two threads. And the most importantone in this paper is the guard . guard is a true of false expressionthat guard the execution of the following statements only if it istrue, otherwise the thread will be blocked until it becomes true. Safety and liveness . We need to dis-cuss these two kinds of properties before going to linear temporallogic, which are introduced by Lamport in 1977 [14]. Safety prop-erty guarantees nothing bad ever happens, e.g., more than twoprocesses access same critical section at the same time will neverhappen. Liveness property denotes as something good eventuallyhappens, e.g., if a process wants to enter its critical section, it caneventually enter. Above is only the informal expression of two typesof properties.
Fairness is another issue of temporal logic. We can not assumerelative speeds of asynchronous processes, there might exist a runthat when a process can execute, but never be executed. This iscalled the unfair processes. Two commonly used variants of fairnessare: weak fairness : If a statement is continuously enabled, it willeventually be executed strong fairness : If a statement is enabled infinitely often, it willeventually be executed
Temporal logic allows us to formalize the properties of a rununambiguously with some special operators. Most relevant to the
Figure 3: Mutual exclusion verification of asynchronous process systems is a specific branchof temporal logic, linear temporal logic (LTL). LTL is sufficient todescribe two operators in the scope of this paper. Let f be a LTLformula. Operators in f such as not , and , or , implication , and equivalence are still a LTL formula. Two further temporal opera-tors global and future are introduced below and Figure 2: □ f : f is true now and forever in rest of the run (cid:94) f : f is true eventually in the future run Let us consider an example of mutual exclusion. Figure 3 containstwo processes and CS is the critical section of that process. Eachprocess is first in non-critical section. If one process wants to accessits shared variables in critical section, it must try to gain lock firstat Try-CS state and leave the critical section as soon as possible.We can write down the LTL formula about mutual exclusion free,starvation free, and deadlock free as follows: mutual exclusion free : □ ¬( CS ∧ CS ) starvation free : □ (cid:94) Try-CS → □ (cid:94) CS deadlock free : □ (cid:94) ( Try-CS ∧ Try-CS ) → □ (cid:94) ( CS ∨ CS ) The first property is simple. Both processes can not access itscritical section at the same time in every state of a run. The restare the liveness properties. Starvation free means if a process try toenter its critical section infinitely often, it will be in critical sectioninfinitely often. And deadlock free property means if both processestry to enter each critical section infinitely often, at least one processcan enter its critical section infinitely often. Note that “infinitelyoften” represents the properties are strong fairness. This is will bediscuss later in section 4.To understand how Spin verifies LTL formula, consider it as agame. Spin negates the LTL formula and converts it into never claim .The never claim is also an automaton that can product togetherwith the model. The Spin model checker then try to find a path thatsatisfied the negated formula which means there exists a counterex-ample in the model that violates the property. On the contrary, if never claim never reaches the acceptance state (never finds a paththat violates the formula) means the model satisfied the formula.
A real-time system is a set of tasks which running interleavingon uniprocessor or concurrently on multi-processors that can sim-ply classify into preemptive and non-preemptive scheduling. Non-preemptive scheduling has lower context switch latency but theinterrupt handler might violate the deadline. And preemptive sched-uling forces each task to process under a limited time and the taskmight be blocked (pending) even if within its timeslice. In this
Spin-based model checking for the simple concurrent program on a preemptive RTOS
ARMv7-M architec-ture [2, 17] uses “exception” as a response to system event and“interrupt” as a peripheral request. Exception (or interrupt) withhigher priority level can preempt the lower one. Moreover, syn-chronous exception like non-maskable interrupt (reset, hardwarefault), system fault, and SVCall must execute before the contextswitch. This means synchronous exception can only be preemptedby higher priority level exception before changing to the next task.The incoming exception will be pending if the priority level is lessthan or equal to the current one. Other exceptions are consideredasynchronous that we can not guarantee the timing of executing,even after the context switching.
Exception entry and exception return are the mechanism beforeand after the exception handler take place on ARMv7-M architec-ture. While an exception occurs, the hardware will compare thepriority of current task and the coming exception. The exceptionentry will push parts of the context into the stack and reset returnvalues of current context if the coming exception is allowed to pre-empt according to the interrupt policy. After finishing the handlertask, the exception return will choose a proper task (from the stackor the pending state) to switch to.
Tail-chaining is the further extension of the exception return.Tail-chaining can continue to process the pending exception at theexception return stage. Rather than restoring to the return contextfrom the stack and saving it back again to the stack, tail-chainingcan directly switch to the pending exception with less timing gap.
Context switch is a significant issue in this paper. Context switchtypically requires processor to execute at a critical region of in-terrupt disabled to avoid the corruption of data during the switch,However, the busy waiting might cause pending the coming excep-tion and violate the deadline. ARMv7-M supports interrupt enabledcontext switch. SVCall is a synchronous exception and triggeredby the svc instruction from user tasks to perform supervisor call.PendSV is an asynchronous software interrupt and handles thescheduling point enabled by the systick handler. To enable interruptduring context switch, the ARMv7-M reference manual suggeststo configure both exceptions with the lowest priority level so thatthey can not preempt each other.
Preemptive scheduling causes thetask to stop and resume executing frequently. One reason is thetask reaches its timeslice and does not finish yet, the schedulerneed switch to the next task from the runqueue. Another reasonis when a task with higher priority added into the runqueue, atany scheduling point the system needs to guarantee the priorityof current task is always the highest one in the runqueue. Thefollowing lists several aspects which will influence the behavior ofthe preemptive scheduling.
Bitmap scheduler has 32 priority levels and two priority arrays,active and expired, which can be swapped in constant time. Thescheduler always chooses the highest priority task from the ac-tive priority runqueue and selected in round-robin way if multipletasks exist in the same priority level. The implementation of array data structure and the bitwise operations make time complexity inconstant time.
Softirq and tasklet . Interrupt handlers are asynchronous and of-ten timing-critical so there are several limitations, such as respondrapidly and cannot be blocked. Softirq is the mechanism that movesthe execution of the non-critical job (bottom half task) from inter-rupt handlers to the user task (softirq process). Moreover, softirqmaintains a bitmap scheduler with only one runqueue to managethe different bottom half tasks, called tasklet.
Mutual exclusion is one of the solutions to prevent race conditionand has different implementations. In this paper, we focus on apair of load-link/store-conditional instructions, ldrex and strex ,supported by a state machine exclusive monitor provided by ARMv7-M architecture. Each processor has a exclusive monitor called localmonitor (we only consider uniprocessor situation here), which willmark a segment of memory address (register) as exclusive by thecalling of ldrex instruction. One local monitor can only mark oneregister at the same time, ldrex will load a value from the addressto the register and clear the previous mark and mark the address asexclusive. strex conditionally stores the value back to the addressif the address is marked as exclusive and clear the mark at the sametime, otherwise the store will fail notifying by the return value. Inbrief, no matter how many times ldrex mark the address, only onecan update the value of that address by strex . And finally, all markwill be cleared at every exception return stage. This make sure theatomic operations of the mutex variables.
Condition variable is an extension of mutual exclusion. It willtemporary release the lock and move itself out of the runqueueif the condition is not satisfied (condition wait). While others getthe lock and satisfy the condition statement, it signals the blockedone by returning the lock and enqueuing the blocked one again(condition signal). This is more efficient than busy waiting becausethe blocked one will temporarily gives up the processor’s resourcesand turns to the process. eChronos [1] is a tiny real-time OS running on ARM Cortex-M3platform developed by Data61 in Australia. They provide a frame-work and prove the property “the running task is always in thehighest priority” on the Isabelle/HOL proof assistant based on theOwicki-Gries [16] method. The OG method is the parallel versionof Hoare logic, known as the pre- and post- condition style, guar-anteeing the shared variables are not interleaving by the parallelprograms. Their framework is delicate and scalable that simulatesboth software and hardware behaviors in one model. But the chal-lenge of their work is the exhausting hand constructed proof andthe lack of implementation details. The reason of the later one isthe proof strategy that they do not declare the explicit interruptpolicy, causing all exceptions can preempt each other. Instead, theyhave proved a larger range of the exception behavior is correct thatcan implicate to the limited and real one.
OSEK-Spin , Zhang, et al. [18] use Spin to verify the application ofa standard automobile OS, OSEK/VDX, which is widely adopted bymany automobile manufacturers. To enhance the user experience,different applications are developed based on the OS. To checkwhether the applications can run correctly, the researcher providea Spin-based model that can replicate the executions on OSEK. Thecorrectness means under the concurrent running task, synchronousevent, and context switch, the user application will not suffer fromrace condition or priority inversion. They also developed boundedmodel checking to verify more complex applications. However, themodel considered only the software aspect and did not contain thespecific hardware behavior.The two researches list above are the most related to our paper.Moreover, there are lots of corresponding work about verifyingsoftware or hardware by mathematical proof, for example, seL4[13]. However, the design of seL4 kernel is optimized for the formalverification, there are some limitations. Although seL4 had analyzedthe WCET [4], its kernel code only has few interrupt points, otherswith interrupt disabled. This is different from the common designof RTOS.
In section 2, we had discussed several factors of scheduling. In thissection, we show how we model those factors by PROMELA. Themodel consists of three static processes (SVC, PendSV, and softirq)and an amount of user tasks and interrupts (number of interruptmust contain one systick). Figure 4 is a schema of 2 user tasks and2 interrupts. The model can separate into three parts: user taskfor the orange box, exception for the blue one, and two specialexceptions SVC and PendSV for the green one. Each process has aPID listed at the top of Figure 4.
We had mentioned that each process are executed in asynchronousorder, we use this feature to simulate the incoming of the IRQs.But to determine which process is the legal one to occupy theresource of processor, eChronos introduced a guard called
AWAITS to control the executing of the processes. Another variable AT (active task) records which process is the legal on to be executed.Every statement in the model will be wrap by AWAITS and can beexecuted only if the AT becomes its PID, otherwise, the statementwill be blocked until AT becomes its PID again. There is also an A_AWAITS statement which do the same thing as
AWAITS , becausethere are two atomic statements in PROMELA, d_step and atomic .Both statements guarantee no other processes can interleave withinthe scope of the statement. The difference is that in verificationstage, the d_step is seen as one step while the atomic is depend onthe statements inside. Note that each statement in the code segmentsurrounding by a frame is wrapped by the
AWAITS or A_AWAITS statements which are the unit operation in our model.Starting from SVC handler first, we modeled five system calls,including, mutex lock, mutex unlock, condition wait, condition sig-nal, and pthread yield. Consider that SVC is synchronous, we usea synchronous channel called rendezvous channel in PROMELAto perform the behavior of calling the system call. It is somethinglike the client/server model that the SVC handler is the server andserves several user tasks. The difference is that other processesremain blocked during the communication. Recall the interruptenabled context switch, PendSV is asynchronous and used to re-spond the scheduling request from the systick. Simultaneously,the systick handler will insert its bottom half task into the tasklet runqueue waiting to be executed in softirq process. Another inter-rupt handler do nothing in the model. Last, we choose the classicconsumer/producer program as our application to verify and thesoftirq will discuss later.
Figure 4 shows that every exception is starts with
ITake or PendSV-Take and ends with
IRet (except SVC is synchronous) which modelsexception entry and exception return. There are two situations in
ITake . First, we refer to the manual of ARMv7-M to implement theinterrupt policy, including the priority and the pending state todetermine whether the incoming IRQs can preempt the currentprocess.
PendSVTake is a simplified
ITake and only affects to thePendSV process. An array
ATStack stores the preempted processesthat has not finished its job yet.
IRet elects the next running taskfrom the top element of
ATStack or the highest priority of pendingstate when the current interrupt handler is finished. If the exceptionpriority of the top of the
ATStack is higher, pop the exception di-rectly to the AT . If not, remember that the exception in pending statehas not been executed yet, an additional variable ghost_direct_AT is introduced to record this situation and can be detected by thesecond condition of ITake . The choosing of pending state runningfirst is similar to the tail-chaining mechanism in ARMv7-MThe design of
ATStack is an array data structure that the lastelement in it must be user task, others are exceptions in priorityorder. The formalization of context switch is to change the lastelement in
ATStack . Because context switch only occurs in SVC orPendSV processes, the only element in
ATStack must be currentuser task and the AT must be the PID of SVC or PendSV. We addseveral assert to check this scene and change the last element in ATStack to reproduce the behavior of context switch.
Two priority runqueues, which contain an unsigned map and aqueue, form the structure of bitmap scheduler. One key differencebetween the model and the source code is the swap of two prior-ity runqueues. The source code uses pointer to swap each other,however, the model uses bitwise operations to do that. Two priorityrunqueues sched_bm[2] are defined in the model. Another globalbit
SCHED_STATE_SWAP is helped to distinguish each runqueue.To swap the runqueues, just xor the swap bit. Additionally, the
ACTIVE and
EXPIRED thread state are designed in the same way.
ACTIVE : ( | SCHED_STATE_SWAP ) EXPIRED : ( ⊕ SCHED_STATE_SWAP ) In short, the softirq is a user process which executes the bottomhalf task of the interrupts. And the tasklet is a one priority runqueuemanaging which bottom half tasks take place first. If no morebottom half task can be executed, the softirq process will give upthe processor’s resource by calling the pthread yield system call.But notice that if the softirq has higher priority than other userprocesses, the system call still choose softirq as next process.The lock and unlock of mutex can split into two stages: non-privilege and privilege because of the supporting of load-link/store-conditional (LL/SC) instructions. Take mutex lock for example, ifthe lock is free then gain lock directly in the non-privilege mode by
Spin-based model checking for the simple concurrent program on a preemptive RTOS Figure 4: The schema of the model (2 user tasks, 2 interrupts) the mechanism of LL/SC, otherwise, calling the mutex lock systemcall to give up the execution (moving itself out of the runqueue).Another point to note that, there must have a place to store thetasks moving out of the runqueue by mutex. The implementation ofthe source code is a linked list structure, we use an array structurein PROMELA, instead. However, to reduce the size of the model,there is only one slot in the array currently and scalable dependingon the applications.Implementation of condition variable is based on the mutex thatwill temporarily release the lock and gain lock again if the conditionis satisfied. Nonetheless, this is difficult to implement in PROMELA.In source code, every process performing context switch in SVC orPendSV handlers which will stop at a specific point in the handlerand resuming when switching back. If we want to emulate thisbehavior in PROMELA model, the SVC and PendSV handler mustduplicate times of the number of user task. This is a great effort formodel checking that we need to share the SVC and PendSV handlerwithin each user task. This leads to another problem that we cannot place two scheduling points in one exception handler and thescheduling point must establish just before the
IRet . This limits themodeling of condition wait system call that we need to use twosystem calls (condition wait and mutex lock) and wrap togetherwith atomic statement to complete the one system call’s job.
We had talked about the model, now discussing the properties andhow we verify the model by Spin model checker.
These two methods are used to verify the correctness of the model: i) assert for safety property, ii) LTL for liveness properties. The assert is not only the safety property but also a useful tool to checkwhether the model is correct during the process of modeling. Weuse assert in the following ways. • The insertion of the queue will not induce buffer overflowand the deletion of the queue must succeed. • If the value of map is not zero, there must be some elementsin the queue. • If the scheduler chooses idle as next thread, the currentthread must not be idle. • The modification of IRQ pending state must be the interruptprocess. • The tail-chaining only happens when no other exceptionpriority in pending state is higher than itself. • The
ATStack will not have buffer overflow. • PendSV can only preempt the user task. • The consumer/producer will not suffer from race conditionusing two global bits cs_c and cs_p to record the entrance ofcritical section. • Only user tasks can perform the system call when there isno pending exception. • Only user tasks can perform context switch when there isno other active exception (excluding SVC and PendSV). • The last element in
ATStack is a user task; others are
UN-KNOWN during the context switch. • Mutex list (array) must not be empty if the value of mutex islarger than zero. • The value of mutex must not smaller than -1.For LTL, we label the condition loop as want , it means that the pro-cess wants to enter its critical section but blocked at the conditionloop. The @ symbol means the execution is at the statement withspecific label. Note that we apply the strong fairness in the LTLformula. If not, the model checker will consider the situation thatthe systick preempt itself forever. But this is impossible that theduration of systick is 1ms in the real-world system. consumer starvation free : □ (cid:94) consumer@want → □ (cid:94) cs_c producer starvation free : □ (cid:94) producer@want → □ (cid:94) cs_p deadlock free : □ (cid:94) ( consumer@want ∧ producer@want ) → □ (cid:94) ( cs_c ∨ cs_p ) ARMv7-M resets the register with UNKNOWN value
Table 1: Options of Spin model checker
Spin Version 6.4.8 - 2 March 2018
Spin options Verification options Runtime options
Safety properties -a -DXUSAFE , -DCOLLAPSE , -m100000000-DSAFETY , -DNOCLAIM , ( -m
Spin options first, -a is needed to gener-ate the verification code and -DLTL is a custom macro that usedto load the LTL properties. In Verification options , -DXUSAFE , -DCOLLAPSE , and -DNOFAIR are used in both properties, the firstone is to disable the usage of xr and xs assertions, the second oneis to compress each state to reduce the memory usage, the thirdone is to disable the weak fairness provided by Spin (we use strongfairness in LTL formula). -DNOCLAIM is to disable the usage of neverclaim, but enables while verifying the LTL properties. -DSAFETY is used in safety property only. -DMEMLIM is the maxima memorythat Spin can use and -DMA is the algorithm of minima automatawhich saving the memory but spending lots of running time. Next,the -m
Safety case uses only assert to verify race condition, which is more efficient than other livenesscases. Because the previous one only checks the specific variable atthe point, however, the
LTL checks the variables along every ω -runs(Figure 1b). Moreover, the meaning of depth and states in Table 2are that the former represents the longest depth of the ω -run andthe later is the number of states that Spin had verified. The state isthe set of all global variables in the model, each statement in themodel might causes the migration from one state to another.The most interesting point is that the usage of memory is ex-treme high, is it really worth it to consume such effort to build the Table 2: The 4 verification resultsDepth States Memory Time
Safety 23,619,898 5.84e+09 314 GB 3.2 hoursconsu_starv 49,295,820 1.01e+10 707 GB 10.4 hoursprodu_starv 49,678,300 1.01e+10 707 GB 10.4 hoursDeadlock 40,484,755 8.11e+09 477.2 GB 6.75 hoursverifications? Remember we had mentioned about
AWAITS state-ment, it is the watershed separating the atomic and concurrentexecuting. Between each
AWAITS (or
A_AWAITS ) statement is aninterrupt point that allowed every non-blocked process to be exe-cuted in different order. There are total 67
AWAITS (and
A_AWAITS )statements in our model, and this is not counting the repeated ones(the inline function of PROMELA will be expended like macro inC language). For example, there are nine scheduling points in themodel (8 in SVC and 1 in PendSV) which means we have to multiplenine times the number of interrupt points under the inline func-tion of scheduling point. It is hard for us to consider such amountof scheduling points at the same time by code review or test cases,how can we check a vulnerability at the depth of 50 million steps?However, with the help of the Model Checking and the powerfulmachine, we can verify those properties within sustainable time.All we have to do is to construct an elegant model which can useless steps to represent the real-world system.Moreover, Spin also provides us an unreached statement listto analyze. The followings reasons are certain for the unreachedstatements. Note that both priority runqueues are not empty at thescheduling points (never switch to idle thread) in this paper. • The scheduling point in PendSV needs to insert current taskto the expired runqueue, while the scheduling point in SVCdon’t. This causes the unreached statements. • If the active runqueue always has some elements, the sched-uler does not need to perform swap statements and the con-dition of next thread equals idle will not be checked. This isbecause there is an enqueue point just before the schedulingpoint. • If the active runqueue is empty and the expired runqueuehas some elements, the condition of next thread equals idlewill not be checked.
Spin-based model checking for the simple concurrent program on a preemptive RTOS • If the next task is equal to the current task, need not toperform context switch. This happens only in the pthreadyield system call. • Two scheduling points in mutex unlock system call neverbeen executed.The last reason is complicated that we need to consider two con-ditions about the mutex unlock system call. First is the system callfrom the condition of LL/SC. The second is called via the conditionwait system call. In the first situation, consider that the currentprocess has the lock, the thread state must not be
BLOCKED . Thefirst scheduling point in mutex unlock system call is guarded by thethread state equals
BLOCKED condition will never be executed un-der first situation. However, the first scheduling point will alwaysbe approached in the second situation. Because the conditionalstatement in mutex unlock system call is deterministic while thesecond scheduling point in mutex unlock system call will never beexecuted. Those are the reason why there are two scheduling pointnot be executed.
We adapt an existing machine-assisted framework to fit the require-ment of model checking and verify several properties of a sim-ple concurrent program under the specific conditions. The modelcontains the simulation of hardware and software aspects. More-over, we do not construct any mathematical proof, the PROMELAlanguage is C-like that anyone can rebuild at any stages of thesystem life cycle by their own (the effort of this paper is about 7man-months and the Piko/RT is still in development) and the veri-fication time is within one day (3 hours for safety property). Thismeans model checking have its advantage on verifying a real-worldsystem at the early stage comparing to the system optimized forformal verification.However, there are still some defects in this paper that need tobe accomplished.(1) The cost (time and memory usage) of adding one processto verify is too expensive in checking the OS source code.There are two possible ways to deal with. First, split themodel into several layers and verify each layer one by one.Another way is to construct proof by hand, Delzanno et al.[8] has proved that using a limited number of process canrepresent the situation of n processes in Spin.(2) How to claim the abstract model and the real-world systemare truly homogeneous. One possible way is to construct amechanism that extract the PROMELA model from the Csource code automatically rather than builds by human.For the second point, we can not claim the model in this paperis totally correct, yet. But we can tell the behave is similar to thetarget system by adding assert , analyzing the unreached statementsor error message, and applying the test cases. In this paper, we usecondition variable to deal with the mutual exclusion problem. Wealso adapted a mutex test case before, and currently, we are tryingto deal with the idle thread problem to look inside the behavior ofthe model.
REFERENCES [1] June Andronick, Corey Lewis, Daniel Matichuk, Carroll Morgan, and Chris-tine Rizkallah. 2016. Proof of OS Scheduling Behavior in the Presence ofInterrupt-Induced Concurrency. In
Interactive Theorem Proving - 7th Interna-tional Conference, ITP 2016, Nancy, France, August 22-25, 2016, Proceedings . 52–68.https://doi.org/10.1007/978-3-319-43144-4_4[2] ARM Limited 2014.
ARMv7-M Architecture Reference Manual . ARM Limited. https://developer.arm.com/docs/ddi0403/e/armv7-m-architecture-reference-manual.[3] Mordechai Ben-Ari. 2008.
Principles of the Spin Model Checker (1 ed.). Springer-Verlag London.[4] B. Blackham, Y. Shi, S. Chattopadhyay, A. Roychoudhury, and G. Heiser. 2011.Timing Analysis of a Protected Operating System Kernel. In
Model Checking .MIT Press, Cambridge, MA, USA.[8] Giorgio Delzanno, Michele Tatarek, and Riccardo Traverso. 2014. Model CheckingPaxos in Spin. In Proceedings Fifth International Symposium on
Games, Automata,Logics and Formal Verification,
Verona, Italy, 10th - 12th September 2014 (ElectronicProceedings in Theoretical Computer Science) , Adriano Peron and Carla Piazza(Eds.), Vol. 161. Open Publishing Association, 131–146. https://doi.org/10.4204/EPTCS.161.13[9] Gerard J. Holzmann. 2003.
Spin Model Checker, the: Primer and Reference Manual (first ed.). Addison-Wesley Professional.[10] Gerard J. Holzmann. 2014. Mars Code.
Commun. ACM
57, 2 (Feb. 2014), 64–73.https://doi.org/10.1145/2560217.2560218[11] Gerard J. Holzmann. 2018. Spin - Formal Verification. (2018). Retrieved April 11,2018 from http://spinroot.com[12] Jim Huang, Yen-Kuan Wu, and Louie Lu. 2018. pikoRT. (2018). Retrieved April11, 2018 from https://github.com/PikoRT/pikoRT[13] Gerwin Klein, Kevin Elphinstone, Gernot Heiser, June Andronick, David Cock,Philip Derrin, Dhammika Elkaduwe, Kai Engelhardt, Rafal Kolanski, MichaelNorrish, Thomas Sewell, Harvey Tuch, and Simon Winwood. 2009. seL4: FormalVerification of an OS Kernel. In
Proceedings of the ACM SIGOPS 22Nd Symposiumon Operating Systems Principles (SOSP ’09) . ACM, New York, NY, USA, 207–220.https://doi.org/10.1145/1629575.1629596[14] Leslie Lamport. 1977. Proving the Correctness of Multiprocess Programs.
IEEETrans. Softw. Eng.
3, 2 (March 1977), 125–143. https://doi.org/10.1109/TSE.1977.229904[15] Leslie Lamport. 1987. A Fast Mutual Exclusion Algorithm.
ACM Trans. Comput.Syst.
5, 1 (Jan. 1987), 1–11. https://doi.org/10.1145/7351.7352[16] Susan Owicki and David Gries. 1976. An Axiomatic Proof Technique for Par-allel Programs I.
Acta Inf.
6, 4 (Dec. 1976), 319–340. https://doi.org/10.1007/BF00268134[17] Joseph Yiu. 2013.
The Definitive Guide to ARM Cortex-M3 and Cortex-M4 Processors (3rd ed.). Newnes, Newton, MA, USA.[18] Haitao Zhang, Toshiaki Aoki, and Yuki Chiba. 2015. A Spin-Based Approachfor Checking OSEK/VDX Applications. In