Asynchronous Programming in a Prioritized Form
aa r X i v : . [ c s . P L ] J a n Asynchronous Programming in a Prioritized Form
Mohamed A. El-Zawawy , College of Computer and Information SciencesAl Imam Mohammad Ibn Saud Islamic UniversityRiyadh, Kingdom of Saudi Arabia Department of MathematicsFaculty of ScienceCairo UniversityGiza 12613, [email protected]
Abstract:
Asynchronous programming has appeared as a programming style that overcomes undesired propertiesof concurrent programming. Typically in asynchronous models of programming, methods are posted into a postlist for latter execution. The order of method executions is serial, but nondeterministic.This paper presents a new and simple, yet powerful, model for asynchronous programming. The proposed modelconsists of two components; a context-free grammar and an operational semantics. The model is supported bythe ability to express important applications. An advantage of our model over related work is that the model sim-plifies the way posted methods are assigned priorities. Another advantage is that the operational semantics usesthe simple concept of singly linked list to simulate the prioritized process of methods posting and execution. Thesimplicity and expressiveness make it relatively easy for analysis algorithms to disclose the otherwise un-capturedprogramming bugs in asynchronous programs.
Key–Words:
Prioritized posting, asynchronous programming, operational semantics, context-free grammar, con-current programming.
All contemporary appliances (mobile, desktop, orweb applications) require high responsiveness whichis conveniently provided by asynchronous program-ming. Hence application program interfaces (APIs)enabling asynchronous, non-blocking tasks, such asweb access or file operations) are accommodatedin dominant programming languages. APIs provideasynchronous programming but mostly in a hard way.For example consider the following situation. Aunique user interface (UI) task thread is typically usedto design and implement user interfaces. Hence eventson that thread simulate tasks that change the UI state.Therefore when the UI cannot be redrawn or respond,it get freezed. This makes it sensible, in order to keepthe application responding continuously to UI tasks,to run blocking I/O commands and long-lasting CPU-bound asynchronously.Asynchronous programming has multi-threadedroots. This is so as APIs have been implemented usingmulti-threaded programs with shared-memory. Soft-ware threads execution is not affected by the numberof processors in the system. This is justified by the fact that the threads are executed as recursive sequen-tial softwares running concurrently with interleavedwrite and reads commands. The many possible inter-leavings in this case cause the complexity of modelsof concurrent programming [8]. In a complex process,atomic locking commands can be added for preven-tion and prediction of bad thread interleavings. Thenon-deterministic style of interleaving occurrence cre-ates rarely appearing programming-errors which aretypically very hard to simulate and fix. This diffi-culty lead researchers to design multi-threaded pro-grams (of APIs) in the framework of asynchronousprogramming models [6, 7].The relative simplicity of asynchronous program-ming makes it a convenient choice to implement APIsor reactive systems. This is proved by recent years in-tense use of asynchronous programming by servers,desktop applications, and embedded systems. Theidea of asynchronous programming is to divide cumu-lative program executions into tasks that are briefly-running. Moreover accessing the shared memory,each task is executed as a recursive sequential soft-ware that specifies (posts) new methods to be executedlater.any attempts were made to present formal asyn-chronous programming models. However few at-tempts [5] were made to express and formalize thefact that posted tasks in asynchronous programs maywell have different execution priorities. A big disad-vantage of existing work [5] that considers executionpriorities is the complexity of the models hosting suchpriorities. For example the work in [5] considers theexecution priorities using several task-buffers whichmakes the solution a bit involved.This paper presents a simple, yet powerful, modelfor asynchronous programming with priorities for taskposting. We call the proposed model A synch P . Thepaper also presents a novel and robust operational se-mantics for the constructs of A synch P . A simplesingly linked list of prioritized posted tasks is used toprecisely capture the posting process. Our proposedasynchronous model is to simplify analyzing asyn-chronous programs [4]. Motivating Example
A motivating example of designing our model comesform the way hardware interactions take place in oper-ating systems (more specifically in Windows) kernels.Concepts of prioritized interrupt sets are used to sim-ulate these hardware interactions in an asynchronousstyle. For such applications a simple, yet powerfuland mathematically well founded, model for priori-tized asynchronous programming is required.
Contribution
The contributions of this paper are: • A prioritized asynchronous programming model; A synch P . • A novel operational semantics for A synch P pro-grams. Organization
The rest of the paper is organized as follows. Section 2presents the proposed prioritized asynchronous pro-gramming model – A synch P . The semantics of pri-oritized asynchronous programming model; A synch P is shown in Section 3 which is followed by Section 4that reviews related work and presents directions forfuture work. The last section (Section 5) of the paperconcludes it. This section presents our model, A synch P , for prior-itized asynchronous programming. In A synch P , eachposted method has an execution priority. An asyn-chronous program execution is typically divided intoquick-running methods (tasks). Tasks of higher pri-ority get executed first and task of equal priorities areexecuted using the first come first serviced strategy.Asynchronous programming has an important appli-cation in reactive systems where a single task mustnot be allowed to run too long and to prevent execut-ing other (potentially) highly prioritized tasks.Figure 1 presents the simple and powerful model A synch P for prioritized asynchronous programming.Considering single local and global variables and us-ing free syntax of expressions does not cause any gen-erality lose. However each expression is built usingthe global variable of the program and the local vari-able of the active method. A A synch P program P consists of a single global variable g and a sequenceof methods denoted M , . . . , M n . The Provided(e) statement continues executing the program providedthat the expression e evaluates to a non-zero value.Each method M is expressed as a structure meth ( m, l, S ) of a method name, a single local vari-able l , and a top-level statement S . The sets of all pro-gram methods and statements are denoted by Meths and
Stmts , respectively. Intuitively, the asynchronouscall is modeled by the statement Synch(m(e),p)where: • the called method name is m , • the calling parameter is the expression e , and • the execution priority of this call is p .We assume three levels of execution priorities; { high (1) , medium (2) , low (3) } . A synch P This section presents a novel operational semanticsfor asynchronous programs built using A synch P . Oursemantics is based on a singly liked-list (which we call Asynchronous Linked List (ALL) ) to host the postedmethods.
ALL is divided into three regions usingpointers. The first, the middle, and last regions of
ALL host posted methods that have high, medium, and lowexecution priorities, respectively.Definition 1 introduces formally the concept of(
Asynchronous Node (AN) ) to be used to build
ALL . ∈ G = Global variable names. l ∈ L = Method local variable names. p ∈ P = { high (1) , medium (2) , low (3) } = The set of all synchronization priorities. m ∈ M = The set of all method names .v ∈ V al = the set of possible values of local and global variables. S ∈ Stats ::= S ; S | g := e | l := e | Provided e | if e then S t else S f | while e do S | run m ( e ) | return () | Synch(m(e),p). M ∈ Meths ::= meth ( m, l, S ) .P ∈ Programs ::= program ( g, M ∗ ) . Figure 1: A synch P : a language model for a simple prioritized asynchronous programming. Definition 1
An asynchronous node (AN), n , is a sin-gle linked list node whose data contents are two loca-tions containing: • x : a method name, and • x : a parameter expression.For a method call m ( e ) in a A synch P program, we letNode m ( e ) denotes the asynchronous node whose lo-cations x and x contain m and e , respectively. Theset of all asynchronous nodes is denoted by Nodes A . Definition 2 introduces formally the concept of
Asynchronous Linked List (ALL) that is to be used toaccurately capturing the semantics of the constructs ofthe proposed asynchronous model.
Definition 2
An asynchronous linked list (ALL), li = < f, c, e h , e m >, (1) is a singly linked list whose nodes are asynchronousnodes (in Nodes A ) such that: • f is a pointer to the first node of the list, • c is a pointer to the current node, and • e h , e m are pointers to the last node in the listhosting a method of high and medium priorities,respectively.The set of all asynchronous linked lists is denoted byLists A . Whenever a method gets posted, an asynchronousnode is created and inserted into an asynchronous list.If the posted method is of priority h or m , the cre-ated node gets inserted after the nodes pointed to by e h or e m , respectively. If the posted method is of pri-ority l , the created node gets inserted at the end of the list. Whenever a posted method is to be executed, themethod corresponding to the head of an asynchronousnode is executed and that head gets removed form thelist. These two operations are assumed to be carriedout by the functions defined in Definition 3. Definition 3
Let li = < f, c, e h , e m > be a asyn-chronous linked list (in Lists A ). We let • add A : Nodes A × P × Lists A → Lists A denotes amap that adds a given node n of a given priority p after the node pointed to be li.e p in a given list li . • remove A : Lists A → Nodes A × Lists A denotesa map that removes the first node of a given list li and return the removed node and the resultinglinked list. Definition 4 introduces the states of our proposedoperational semantics.
Definition 4
Let program ( g, M , . . . , M n ) , where M i = meth ( m i , l i , S i ) , be a program in A synch P . Anasynchronous program state (APS) is a triple (s,li,sk),where: • s is a partial map from G ∪ ( M × L ) to Val. • li is an asynchronous linked list. • sk is stack of method names.We let M i .l and M i .l denote l i and S i , respectively. Each semantic state is a triple of a partial map capturesthe contents of global and local variables, an asyn-chronous linked list, and a stack of method names. Note that p ∈ { h, m, l } . If p = l, e l is the last node in thelist i ′ = add A ( Node ( m ( e )) , p, li ) ( synch s ) Synch ( m ( e ) , p )) : ( s, li, sk ) → ( s, li ′ , sk ) is-empty ( sk ) = false sk ′ = pop ( sk ) ( return s ) return () : ( s, li, sk ) → ( s, li, sk ′ ) m ′ = peek ( sk ) v = k e ( s ( g ) , s ( m ′ .l ) k s ′′ = s [ m.l v ] sk ′′ = push ( sk, m ) m.S : ( s ′′ , li, sk ′′ ) → ( s ′ , li ′ , sk ′ ) ( run s ) run m ( e ) : ( s, li, sk ) → ( s ′ , li ′ , sk ′ ) m ′ = peek ( sk ) v = k e ( s.g, m ′ .l ) k (:= sg ) g := e : ( s, li, sk ) → ( s [ g v ] , li, sk ) m ′ = peek ( sk ) v = k e ( s.g, m ′ .l ) k (:= sl ) l := e : ( s, li, sk ) → ( s [ m ′ .l v ] , li, sk ) m ′ = peek ( sk ) k e ( s.g, m ′ .l ) k 6 = 0 ( p s ) Provided e : ( s, li, sk ) → ( s, li, sk ) m ′ = peek ( sk ) k e ( s.g, m ′ .l ) k = 0 ( w s ) while e do S : ( s, li, sk ) → ( s, li, sk ) m ′ = peek ( sk ) k e ( s.g, m ′ .l ) k 6 = 0 S : ( s, li, sk ) → ( s ′′ , li ′′ , sk ′′ ) while e do S : ( s ′′ , li ′′ , sk ′′ ) → ( s ′ , li ′ , sk ′ ) ( w s ) while e do S : ( s, li, sk ) → ( s ′ , li ′ , sk ′ ) m ′ = peek ( sk ) k e ( s.g, m ′ .l ) k = 0 S f : ( s, li, sk ) → ( s ′ , li ′ , sk ′ ) ( if s ) if e then S t else S f : ( s, li, sk ) → ( s ′ , li ′ , sk ′ ) m ′ = peek ( sk ) k e ( s.g, m ′ .l ) k 6 = 0 S t : ( s, li, sk ) → ( s ′ , li ′ , sk ′ ) ( if s ) if e then S t else S f : ( s, li, sk ) → ( s ′ , li ′ , sk ′ ) S : ( s, li, sk ) → ( s ′′ , li ′′ , sk ′′ ) S : ( s ′′ , li ′′ , sk ′′ ) → ( s ′ , li ′ , sk ′ ) (; s ) S ; S : ( s, li, sk ) → ( s ′ , li ′ , sk ′ ) Figure 2: Transition rules for statements.The stack is meant to keep the order in which methodscall each other.Figures 2 and 3 present the transition rules of theproposed operational semantics. Some comments onthe rules are in order. The rule synch s creates an asyn-chronous node corresponding to the method m and theparameter e . Using the map add A , the node then isadded to the asynchronous list li to get the new list li ′ .The rule ( return s ) , pops an element from the methodstack as the return statement means that the top ele-ment of the stack is executed. The rule ( run s ) firstpeeks the first element of the stack to get the local vari-able ( m ′ .l ) of the currently active method. This localvariable is then used together with the global variableto evaluate the expression e . The resulting value isused to modify the local variable of the method ( m )that is to be executed. Then m is pushed into the stackand the statement of m is executed. The rule ( prog s ) first runs the statements of allmethods of the program being executed then runs allstatements of the methods that is posted. The postedstatements are executed via the rules ( ⇒ s ) and ( ⇒ s ) . Parallel, distributed, reactive, and concurrent pro-gramming have been attracting much researcher activ-ities. The asynchronous programming methodologiesinclude: • multi-threaded light-weight orchestration pro-gramming [19], • thread Join-based allocation, • typed synchronous programming languages [20], • functional sensible programming, ⇒ s )( s, empty , empty ) ⇒ ( s, empty , empty )( n, li ′ ) = remove A ( li ) n.x .S : ( s, li ′ , empty ) → ( s ′′ , li ′′ , empty )( s ′′ , li ′′ , empty ) ⇒ ( s ′ , empty , empty ) ( ⇒ s )( s, li, empty ) ⇒ ( s ′ , empty , empty ) sk ′′ = push ( m, sk ) S : ( s, li, sk ′′ ) → ( s ′ , li ′ , sk ′ ) ( meth s ) meth ( m, l, S ) : ( s, li, sk ) → ( s ′ , li ′ , sk ′ ) ∀ ≤ i ≤ n. M i : ( s i , li i , sk i ) → ( s i +1 , li i +1 , sk i +1 )( s n +1 , li n +1 , empty ) ⇒ ( s ′ , empty , empty ) ( prog s ) program ( g, M , . . . , M n ) : ( s , li , sk ) → ( s ′ , empty , empty ) Figure 3: Transition rules for methods and programs. • promises, and • co-methods and futures agents [21, 22].Event-based techniques for programming have beenusing continuations which are delimited monadic [17,18]. Fork-join, task, async, and event functions appearnot to rely on a specific language design. There isa big research debate about the relationship betweenthreads and events in systems research [16].In an asynchronous program, executions contain-ing context switches bounded by a user-specified limitare explored by context-bounded verification [14, 15].This context-bounding idea is not reasonable for pro-grams with big number of events. Several treatmentsfor this problem have been proposed for this prob-lem. Without losing decidability, [13] proposed acontext-minimizing technique permitting unboundedcontext switches. For asynchronous concurrent pro-grams, in [12], the round-robin technique for schedul-ing is used to enable unbounded context switches.Sequential techniques are also used to analyzeasynchronous programs. In [14], a source-to-sourcetechnique building sequential programs from multi-threaded programs was proposed via under approxi-mating the possible set of executions of the input pro-gram. A novel source-to-source transformation pro-viding for any context-bound, a context-bounded un-der approximation was presented in [11]. A mainissue of the work in [11] is that the resulting se-quential program may host main states unreachablein the given asynchronous program. Other techniqueslike [10] treat this problem by repeatedly running thecode to the control points where used-defined val-ued are needed. The work in [9] compares the tech-niques of asynchronous programs verifications thatuse verification-condition-checking against that usemodel-checking. One major results of this work is thateager approaches outperforms lazy ones. The workin [8] uses the construction using a bound on the task number, to reduce asynchronous programs into se-quential programs via priority-preemptive schedulers.The work presented in this paper is close to se-quentialization [14]; the concept describing composi-tional reductions to get sequential programs from con-current ones. Although sequentialization started bychecking multi-threaded programs with one context-switch, it was developed later to treat a user-specifiednumber of context-switches. These switches occuramong statically-specified group of threads runningusing RR order [11]. In [2], a technique for treat-ing context switches among an unspecified number ofdynamically-created tasks was presented. This tech-nique (in [2]) hence explicitly treats event-orientedasynchronous programs.For future work, it is interesting to devise staticanalyses for asynchronous programs using the model A synch P [1]. Initial experiments show that our pro-posed model is expected to support devising robustand powerful analysis techniques. An examples oftargeted analyses is dead-posting elimination whichaims at removing the unnecessary posting statementsfrom asynchronous programs. Main reason to use asynchronous programming isto overcome some problems of concurrent program-ming. The main idea of asynchronous programmingis to post methods into a post list for latter execution.The order of executing these methods is nondetermin-istically serial.A new and simple, yet powerful, model for asyn-chronous programming was presented in this pa-per. More precisely, the paper proposed a context-free grammar and an operational semantics for asyn-chronous programming. One important aspect of theproposed model is supporting posting methods withxecution priorities.
References: [1] El-Zawawy, M.A.: Detection of probabilisticdangling references in multi-core programs us-ing proof-supported tools. In: Murgante, B.,Misra, S., Carlini, M., Torre, C.M., Nguyen, H.-Q., Taniar, D., Apduhan, B.O., Gervasi, O. (eds.)ICCSA 2013, Part V.
LNCS , vol. 7975, Springer,Heidelberg (2013), pp. 516–530.[2] M. Emmi, S. Qadeer, and Z. Rakamaric. Delay-bounded scheduling. In POPL 11:
Proc. 38thACM SIGPLAN-SIGACT Symposium on Princi-ples of Programming Languages , ACM, 2011,pp. 411–422.[3] N. Kidd, S. Jagannathan, and J. Vitek. One stackto run them all: Reducing concurrent analysisto sequential analysis under priority scheduling.In
SPIN 10: Proc. 17th International Workshopon Model Checking Software , volume 6349 ofLNCS, Springer, 2010, pp. 245–261.[4] M. F. Atig, A. Bouajjani, and T. Touili. Analyz-ing asynchronous programs with preemption. InFSTTCS 08: Proc.
IARCS Annual Conferenceon Foundations of Software Technology and The-oretical Computer Science , volume 2 of LIPIcs,Schloss Dagstuhl - Leibniz-Zentrum fuer Infor-matik, 2008, pp. 37–48.[5] Michael Emmi, Akash Lal, Shaz Qadeer: Asyn-chronous programs with prioritized task-buffers.
SIGSOFT FSE
CAV 06: Proc. 18th Inter-national Conference on Computer Aided Ver-ification , volume 4144 of LNCS, Springer,2006,pp. 300–314.[7] R. Jhala and R. Majumdar. Interprocedural anal-ysis of asynchronous programs. In
POPL 07:Proc. 34th ACM SIGPLAN-SIGACT Sympo-sium on Principles of Programming Languages ,ACM, 2007, pp. 339–350.[8] N. Kidd, S. Jagannathan, and J. Vitek. One stackto run them all: Reducing concurrent analysisto sequential analysis under priority scheduling.In
SPIN ’10: Proc. 17th International Workshopon Model Check- ing Software , volume 6349 ofLNCS, Springer, 2010, pp. 245–261.[9] N. Ghafari, A. J. Hu, and Z. Rakamarifc. Con-textbounded translations for concurrent soft-ware: An empirical evaluation. In
SPIN ’10:Proc. 17th Interna- tional Workshop on Model Checking Software , volume 6349 of LNCS,Springer, 2010, pp. 227–244.[10] S. La Torre, P. Madhusudan, and G. Parlato. Re-ducing context-bounded concurrent reachabilityto sequential reachability. In
CAV ’09: Proc. 21stInternational Conference on Computer AidedVerification , volume 5643 of LNCS, Springer,2009, pp. 477–492.[11] A. Lal and T. W. Reps. Reducing concurrentanalysis under a context bound to sequentialanalysis.
Formal Methods in System Design ,35(1), 2009, pp. 73–97.[12] S. La Torre, P. Madhusudan, and G. Par-lato. Modelchecking parameterized concurrentprograms using linear interfaces. In
CAV ’10:Proc. 22nd International Conference on Com-puter Aided Verification , volume 6174 of LNCS,Springer, 2010, pp. 629–644.[13] M. F. Atig, A. Bouajjani, and S. Qadeer. Con-textbounded analysis for concurrent programswith dynamic creation of threads. In
TACAS ’09:Proc. 15th International Conference on Toolsand Algorithms for the Construction and Analy-sis of Systems , volume 5505 of LNCS, Springer,2009, pp. 107–123.[14] S. Qadeer and D.Wu. KISS: Keep it simple andsequential. In
PLDI ’04: Proc. ACM SIGPLANConference on Programming Language Designand Implementation, ACM , 2004, pp. 14–24.[15] S. Qadeer and J. Rehof. Context-bounded modelchecking of concurrent software. In TACAS ’05:Proc. , volume 3440 of LNCS, Springer,2005, pp 93–107.[16] G. Kerneis, J. Chroboczek, Continuation-Passing C, compiling threads to events throughcontinuations,
Higher-Order and SymbolicComputation (LISP) , 24(3), 2011, pp. 239–279.[17] A. Holzer, L. Ziarek, K. Jayaram, P Eugster,Putting events in context: aspects for event-based distributed programming,
AOSD , 2011,pp. 241–252.[18] L. Vaseux, F. Otero, T. Castle, C. Johnson,Event-based graphical monitoring in theEpochX genetic programming framework,
GECCO (Companion) , 2013, pp. 1309–1316.[19] R. Ranjan, B. Benatallah, Programming CloudResource Orchestration Framework: Operationsand Research Challenges,
CoRR abs/1204 , 2204,2012.[20] J. Aguado, M. Mendler, R. Hanxleden,I. Fuhrmann, Grounding Synchronous Deter-ministic Concurrency in Sequential Program-ming.
ESOP , 2014, pp. 229–248.21] G. Gori, E. Johnsen, R. Schlatte, V. Stolz,Erlang-Style Error Recovery for Concurrent Ob-jects with Cooperative Scheduling.
ISoLA , 2014,pp. 5–21.[22] J. Nelson, Co-ops: concurrent algorithmic skele-tons for Erlang.