Preventing Recursion Deadlo ck in Concurrent Ob jectOriented Systems by Eric A Brewer Carl A Waldspurger Technical Rep ort MITLCSTR January Abstract This pap er presents solutions to the problem of deadlo ck due to recursion in concurrent ob ject oriented programming languages Two languageindep endent systemlevel mechanisms for solving this problem are prop osed a novel technique using multiported objects and a named threads scheme that b orrows from previous work in distributed computing We compare the solutions and present an analysis of their relative merits Keywords deadlo ck recursion ob jectoriented systems programming languages concurrency c Massachusetts Institute of Technology This work was supp orted in part by the National Science Foundation under grant CCR by the Defense Advanced Research Pro jects Agency DARPA under Contract NJ and by an equipment grant from Digital Equipment Corp oration Eric A Brewer was supp orted by an Oce of Naval Research Fellowship Massachusetts Institute of Technology Lab oratory for Computer Science Cambridge Massachusetts INTRODUCTION Introduction Recursion is a p owerful programming technique that allows straightforward expression of many algorithms Unfortunately recursion often leads to deadlo ck in contemporary concurrent ob ject oriented systems In many systems Ame Yon Man Chi a metho d that mo dies an ob jects state cannot even call itself recursively This o ccurs b ecause the ob ject as sender is blo cked waiting for its call to complete but the called metho d never executes b ecause the ob ject as receiver is blo cked In general recursion deadlock o ccurs whenever an ob ject is blo cked p ending a result whose computation requires the invocation of additional metho ds on that same ob ject We present two transparent solutions that allow general recursion without deadlo ck These solutions are transparent in that programs suering from recursion deadlo ck will run correctly without change if either solution is incorp orated into the underlying system The rst solution is based on multiported objects and uses separate communication p orts to identify recursive calls The second solution named threads draws on previous work in distributed computing and generates a unique name for each thread in order to detect recursive calls A combination of three factors leads to recursion deadlo ck First an ob ject must hold a lo ck on some state In systems with at most one active thread p er ob ject Ame Yon Man Chi there is a single implicit lo ck for the entire ob ject state Second the ob ject must make a blo cking call to some ob ject p ossibly itself holding the lo ck while it waits for the resp onse to the call Finally the resulting call graph must contain a call back to the lo cked ob ject that requires access to the lo cked state forming a cycle When these criteria are met every ob ject involved in the cycle is waiting for a reply but none of the ob jects can make any progress The ob jects on the cycle are deadlo cked Aside from simple recursive metho ds many patterns of messagepassing can lead to recur sion deadlo ck A common practice in programming sequential ob jectoriented systems is to use a metho d as a mo dular subroutine from within another metho d dened on the same ob ject An attempt to do this in a concurrent system however will result in deadlo ck More sophisticated programs that manipulate cyclic data structures use callbacks while resp onding to unusual or exceptional conditions or implement dynamic sharing mechanisms are all candi dates for recursion deadlo ck Some programming styles are also prone to recursion deadlo ck For example using inheritance by delegation Lie Lie an ob ject can delegate the handling of a metho d to another ob ject dynamically In a delegated call references to self should b e 1 resolved to the original ob ject that p erformed the delegation Thus all calls to self involve 1 The term self may b e somewhat misleading in this context Whenever a message is delegated it must callbacks that could lead to recursion deadlo ck In the next section we examine existing work related to the recursion deadlo ck problem Our basic mo del of concurrent ob jectoriented systems is dened in section Section discusses the semantics of recursion without deadlo ck In section we outline our general solution framework and we present the solutions in sections and An illustrative example app ears in section Finally we compare the solutions in section and then present our conclusions Related Work A variety of partial solutions exist for handling some cases of recursion deadlo ck The simplest partial solutions handle only direct recursion involving a single ob ject These amount to re leasing the ob ject lo ck and ensuring that the next metho d invoked is the recursive call eg by prep ending it to the incoming message queue which will reacquire the lo ck This approach is implicit in languages such as Vulcan Kah which ensure that calls to self are pro cessed b efore other incoming messages Another solution for direct recursion is to provide procedures in addition to metho ds Yon Unlike metho ds pro cedures are stateless and need not b e asso ciated with an ob ject Since pro cedures are stateless they do not require lo cks Using this approach a metho d calls a pro cedure and the pro cedure handles the recursion This avoids deadlo ck b ecause there is no lo ck acquisition assuming the pro cedures never invoke any metho ds Recursion deadlo ck is p ossible if the pro cedures invoke metho ds or otherwise acquire lo cks Since pro cedures only have access to the current ob jects state multipleob ject recursion is not p ossible A partial solution for xeddepth recursion is the use of selective message acceptance con structs Yon Ame For example ABCL allows calls to b e accepted in the b o dy of a metho d if the ob ject enters a selective waiting mo de In this case the recursive call is handled in the b o dy and need not acquire the ob ject lo ck An explicit waiting mo de must b e introduced for each level of recursion if there are to o many recursive calls the system will deadlo ck If recursive calling patterns are completely known in advance deadlo ck can b e avoided in actor systems by using replacement actors By cleverly sp ecifying insensitive actors that buer most incoming messages while resp onding to a few sp ecial messages such as become programmers can write co de that explicitly avoids p otential deadlo cks Agh Insensitive actors are automatically generated by compilers for actor languages to supp ort the acceptance of include a reference to the client ob ject that originall y received the message The term client is used b ecause the ob ject that is the target of the delegation can b e thought of as p erforming a service for the original ob ject Lie COMPUTATIONAL MODEL 2 replies to messages sent by a lo cked actor Although actor replacement provides the exibili ty required to write deadlo ckfree co de the complexity of explicitly introducing insensitive actors and b ehaviors for all p ossible recursive calling patterns is daunting In fact these lowlevel actor mechanisms could b e used to implement the solutions we prop ose without systemlevel changes In general systems that provide linguistic control of message acceptance such as enabledsets Tom or protocols Bos can b e used to implement our languageindep endent solutions Techniques for deadlock detection from the distributed systems and database literature Gli Sin could also b e used to address the recursion deadlo ck problem Deadlo ck de tection algorithms examine pro cess and resource interactions to nd cycles assumed to b e relatively infrequent and usually op erate autonomously separate from normal system activi ties Although such schemes theoretically could b e used to detect and recover from deadlo cks in a concurrent ob jectoriented system they would not b e practical for negrained programs that use recursion Nevertheless the general idea of maintaining a list of blo ckedprocess de p endencies is related to the deadlo ckprevention techniques that we prop ose Finally recursion deadlo ck is closely related to the nestedmonitor problem Lis In the nestedmonitor problem monitors corresp ond to ob jects with a single lo ck Nestedmonitor calls corresp ond to blo cking calls made while an ob ject holds its lo ck Thus deadlo ck o ccurs if 3 there is a cycle in the call chain Most work on the nestedmonitor problem o ccurred b efore the advent of concurrent ob jectoriented languages Solutions presented during that p erio d amounted to either releasing the lo ck across the call or forbidding calls entirely Had Computational Mo del We make a few basic assumptions ab out the underlying computational mo del The mo del we assume encompasses most contemporary concurrent ob jectoriented systems Objects abstractly encapsulate lo cal state with a set of methods that can manipulate that state directly Ob jects interact only by sending messages to invoke metho ds at other ob jects To avoid ambiguity we dene the following terms Message A message is a request from a sender ob ject to a receiver ob ject to p erform an op eration A message causes the invocation of a particular metho d at the receiver the 2 In actor parlance an actor that has not yet computed its replacement b ehavior 3 The nestedmonitor problem is not restricted to cyclic calls At the time other forms of deadlo ck were the primary concern arguments for that metho d are passed in the message Messages may or may not arrive in the order they were sent but message