Abstract A Complete Guide to the Future

A Complete Guide to the FutureFrank S.de Boer Dave ClarkeCWIAmsterdam,Netherlands Einar Broch Johnsen Department of Informatics University of OsloAbstractWe present the semantics and proof theory for an object-oriented language with active objects,asynchronous method calls,and fu-tures.The language,based on Creol,distinguishes itself in that un-like active object models,it permits more than one thread of control within an object,though,unlike Java,only can be active within an object and rescheduling occurs only at specific release points.A consequence is that it reestablishing an object’s monitor invariant becomes possible at specific well-defined points in the code.The main technical result of this paper is a complete proof theory for reasoning about our language.This proof theory is simple com-pared to previous work on similar proof theories for Java.This is evidence that the present approach to concurrency is simpler to rea-son about than,say,Java’s multithreaded concurrency model.From a methodological perspective,we identify constructs which admit a simple proof theory and those which require more complicated means such as interference freedom tests.Categories and Subject Descriptors F.3.1[Specifying and Verify-ing and Reasoning about Programs]:Logics of programs General Terms Languages,VerificationKeywords distributed programming,object-oriented program-ming,asynchronous method call,futures,proof theory1.IntroductionThe increasing importance of distributed systems emphasizesflex-ible communication forms between distributed processes.While object-orientation appears to be a natural paradigm for distributed systems[18],the tight coupling between objects traditionally en-forced by method calls may be criticized.Asynchronous method calls have been proposed as a means to combine object-orientation with distributed programming,allowing a looser coupling between a caller and a callee than in the tightly synchronized(remote) method invocation model.Return values from asynchronous calls are assigned to so-called futures[4,11,14,21,28].In this paper, we develop a kernel language for distributed concurrent objects in which asynchronous method calls is the basic communication construct.Concurrent objects are potentially active:synchronized communication as well as sequential execution appear as special cases of asynchronous method calls between objects.The proposed[copyright notice will appear here]kernel language combines the concurrency model of Creol[19],an object-oriented language for concurrent objects,withfirst-order fu-tures,and is presented in a Java-like syntax.Futures are not trans-parent but may be communicated between objects,enabling future return values from asynchronous method calls to be shared among the concurrent objects.The paper presents a operational semantics and type system for this kernel language,establishes type sound-ness,and introduces a novel proof theory for concurrent objects with asynchronous method calls and futures.The adopted concurrency model is based on concurrent objects, each with its own processor.Inside a concurrent object,method activations are executed in an interleaved way.Thus execution in an object is reminiscent of monitors,but explicit signaling is avoided by introducing so-called release points at which control may change between different method activations competing for the object processor.The interleaved execution of method activa-tions allows different activities to be pursued within the concurrent object;in particular,active and reactive object behavior are easily and dynamically combined within an object.Whereas an active ob-ject usually relies on some preselected method to define its active behavior,we exploit asynchronous method calls as triggers of con-current activity.Any method may be called both synchronously and asynchronously.In fact,synchronous method calls will be treated as a special case of asynchronous calls,for which execution blocks while waiting for the reply.Thus,synchronous calls restrict the nat-ural concurrency of the model by sequentializing activity.Asyn-chronous method calls may be regarded as a delegation technique, spawning concurrent activities in other objects while the caller pro-ceeds with its execution.Futures extend this technique to include the forwarding and sharing of replies to method invocations.As futures are statically recognized,each object sharing a future may choose to either block,with or without releasing control while wait-ing for the reply associated with the future.Proof theories for multithreaded object systems are complicated by the interference problem for shared variables,which appears when threads operate concurrently in the same object.Reasoning about programs in this setting is highly complex[1]:Safety is by convention rather than by language design[3].The simplicity of the proof theory proposed in this paper,in contrast to that of, e.g.,multithreaded Java,is a major advantage of concurrent object models compared to multithread concurrency.The proposed proof theory uses a local assertion language to describe the local state of an object.Local assertions are used to express the pre-and postconditions of methods and the monitor invariants.On the other hand,a global assertion language is used for describing invariant properties of inter-object synchronization. In this paper we present a novel view of an object as maintain-ing multiple local monitor invariants and a global synchronization constraint.The local invariants monitor the different release points of an object.These multiple monitors require a novel proof theory for their mutual dependencies in establishing their invariance.This12006/10/2clear separation of concerns between intra-and inter-object syn-chronization is reflected in the completeness proof which is based on a semantic characterization of the global invariant in terms of futures and local history variables which record for each object its externally observable behavior,as specified by its method calls, method invocations,and its return statements.The internal schedul-ing in an object is completely encapsulated by its local invariants, recording snapshots of the corresponding release points. Paper overview.Sect.2introduces the syntax and operational semantics of the kernel language,Sect.3defines its type system and establishes type soundness,and Sect.4provides an example. Sect.5introduces the assertion language,Sect.6a proof theory for concurrent objects with asynchronous method calls,and Sect.7 establishes the completeness of the proof system.Sect.8discusses related work and Sect.9concludes the paper.2.The LanguageA kernel language for distributed concurrent objects with asyn-chronous method calls is now introduced,adopting much of the syntax of Featherweight Java[17].The semantics of the language is given as a contextual,small-step operational semantics[10]. An object may be understood as an encapsulated state on which various processes are executed.Objects are concurrent in the sense that each object has a thread dedicated to executing the processes of that object,so processes in different objects can execute concur-rently.Each process in an object corresponds to the activation of one of the object’s methods.The object’s state variables can only be manipulated by its own methods.The state is encapsulated in the sense that external manipulation of the object state is indirect by means of calls to the object’s method.In order to preserve an ob-ject’s invariants for reasoning control,execution is restricted such that only one process may be active in an object at a time;other pro-cesses in the object are suspended.We distinguish between block-ing a process and releasing a process.Blocking causes the execu-tion of the process to stop,but does not hand control over to a sus-pended process.Releasing a process stops execution of that process and reschedules control to another(suspended)process.Thus,if a process is blocked there is no execution in the object,whereas if a process is released another process in the object may execute.Al-though processes need not terminate,the object may combine the execution of several processes using release points within method bodies.At a release point,the active process may be released and a suspended process may be activated.A process which makes a remote method call must wait for the return of the call before proceeding with its activity.In a distributed setting this limitation is severe;delays and instabilities may cause much unnecessary waiting.In an unreliable environment in which communication can disappear,the object can even be permanently blocked(and the object deadlocked).By assigning the result value from a method call to a future variable instead of an ordinary variable,the blocking of the process is delayed until the result value from the method needs to be retrieved from the variable. When we attempt to read from a state variable which does not have an assigned value,we get the default value for the type of that variable(e.g.,for object pointers).When we attempt to read from a future variable which does not have an assigned value,the execution is blocked.Future variables may also be polled,enabling fine grained control of scheduling.The Boolean polling operation on a future variable returns when reading the variable will not block and otherwise.(In contrast to the read operation on the future variable,the polling operation never blocks.) Release points in the language are expressed using Boolean guards.The release points influence the implicit controlflow inside objects by allowing process blokcing when the guard evaluates to .As the polling of a future variable is a Boolean operation,srsrsrmay befields()or variables(),and is a class name. future variables can also be tested within the guards at release points.This way,processes are allowed to choose between blocking and releasing control while waiting for the reply to a method call. Remark that the use of release points makes it straightforward to combine active(e.g.,nonterminating)and reactive processes in an object.Thus,an object may behave both as a client and as a server for other objects without the need for an active loop to control the interleaving of these different roles.2.1SyntaxThe language syntax,given in Fig.1,is now briefly presented,em-phasizing constructs which differ from Java.A program is a list of class definitions followed by a method body.A class inherits from a single superclass,which may be,extending the su-perclass by declaring additionalfields and methods.To en-force a proper encapsulation of objects,the internalfields of ob-jects are not externally accessible.Methods may have local vari-ables,which are declared at the start of a method body.Thus,vari-ables may befields or local process variables.Access to the object instance running the current method is available through the self reference,and access to the future variable which will contain the result of executing the current method is available through the local non-assignable pseudo-variable.The language expressions include,variable access, for both the local process variables and thefields of the current object,and object creation.In addition there are two non-standard expressions:an asynchronous method call and the (blocking)read operation on a future variable,denoted. The language statements contain the standard statements ,assignment,the conditional, sequential composition,and three non-Java statements:release points for guards,non-deterministic choice be-tween the two branches and,and merge for the inter-leaved execution of the two branches.Guards are either the uncon-ditional release guard,Boolean expressions,the polling op-eration on a future variable,or the conjunction of guards. When the guard evaluates to,the release point allows the pro-cess to proceed.When the guard evaluates to,the release point allows the active thread in an object to be release and another pending thread to be rescheduled.Non-deterministic choice allows either branch to be selected.The merge allows its branches to be in-terleaved at release points without yielding control to other pending threads.Similar to how release points influence the inter-process flow of control in an object,the merge allows release points to influence the intra-processflow of control without allowing other processes to access the object processor.The additional statements,and appear as in-termediate expressions during reduction.The statement is introduced during the unsuccessful reduction of an state-22006/10/2config object comp config configobject processQ fds active-processoidfds f vcomp mid mode void mactive-process processprocess srprocessQ process processQ processQv oid midFigure2.The syntax for runtime configurations.Here,oid and mid denote identifiers for objects,and futures.Processes include both the types of local variables and the expected return type(which we often elide for simplicity of presentation).ment(when the guard is),and the statement corre-sponds to the activation of statement in the merge of statements and inside a process,where statement is paused.2.2SemanticsThe semantics of our language is presented as a small step reduc-tion semantics between configurations,in a reduction context style. Reduction steps may be performed in parallel.A configuration consists of a multiset of objects and futures. The syntax of configurations is presented in Fig.2.In a configura-tion,an object represents the runtime state of a class instance,and a future represents the runtime state of a method call and stores the eventual result of executing the call.A future starts its lifetime con-taining the method invocation.In a future,the called method is denoted oid m.The method is subsequently activated and placed on the process queue of an object.Finally,the future contains the result of executing the method invocation.Future variables in the program reference such futures.The value mode represents a mode of the future,mode(representing modes sleep,active, and completed).Objects consist of an object identifier and the class of the object,a queue of blocked processes,fields,and an active process.Processes correspond to method activations and may be either active or blocked.The process indicates that an object is not currently running a method.The types have default values,given by the default function:defaultdefaultdefaultThe initial configuration of a program sr has one object default sr,for some object identifier. Reduction contexts and redexes.The main part of the semantics provides rules for reducing processes by decomposing a statement into a reduction context and a redex,and reducing the redex.The scheduling of execution between different processes in objects and between different parts of a configuration are handled by additional rules outside of reduction contexts.Reduction contexts are method bodies,statements,expressions,and guards with a single hole,denoted by and defined as follows:Different redexes are reduced in the different reduction contexts;i.e.,body-redexes are reduced in context,stat-redexes in, expr-redexes in,guard redexes in,and body-redexes in. Redexes are defined as follows:body-redexesstat-redexesexpr-redexesguard-redexes midThe operation offilling the hole of a context with an ex-pression of the appropriate kind is denoted.For example when evaluating a method body of the form, we have where is a method context and is a redex of the appropriate kind.Note that when it becomes time to evaluate the expression in the method body,the method body will have been reduced to the form.For simplicity, we elide the and write just.The reduction relation takes the form config config.Rules may apply to partial configurations,so long as the elements in-volved in the reduction are defined.This is in contrast to,e.g.,ap-proaches to the semantics of imperative object-oriented languages with a global store in the configuration[12],but it is consistent with the Creol’s executable operational semantics[19]based on multi-set rewrite rules in rewriting logic[5,22].This approach allows true concurrency in the distributed setting.The most interesting reduc-tion rules are discussed in the following paragraphs,the remaining rules are available in Appendix A.Reduction rules for expressions.An asynchronous method call creates a new,sleeping future in the configuration,containing the details of the call.The identifier of the future is returned immedi-ately to the caller,who can then proceed.(R ED-C ALL)mid is freshpq fds oidpq fds mid mid oidA read operation on a future variable blocks the active process until the original asynchronous method call has been completed, i.e.,when the future with identifier mid in the rule below is in (completed)mode.Note that blocking the active process does not reschedule another pending process on the same object.(R ED-G ET)fds mid midfds midIffields are thefields of a class,let defaults default.Object creation introduces an instance of class in the configuration,giving default values to the new object’sfields:(R ED-N EW)oid is fresh fds’defaultspq fdspq fds oid fds’Remark that if constructor methods were added to the language, object creation could also be defined as an asynchronous operation in a similar manner as asynchonous method calls. Reduction rules for guards.Guards determine whether a process should be released and another process rescheduled.The polling on32006/10/2a future variable determines whether a future has completed:(R ED-P OLL)pq fds mid mid modepq fds mid modeNote that in contrast to(R ED-G ET),polling a future at a release point()enables the release of the active process and the rescheduling of a blocked process inside the object.A guard in an expression,for example, will always cause the release of the active process:(R ED-W AIT)pq fds pq fdsReduction rules for statements.A process at a release point will proceed whenever the guard is true.Otherwise it will release.When the process is released,the same guard is reused when eventually rescheduling the process,except that any clauses are removed from the guard.Thus the effect of,e.g.,is to uncon-ditionally release an active process,but in the released process the statement replaces the statement above. When the process becomes a canditate for rescheduling its guard will be and the process is able to proceed.(R ED-A WAIT)fdsfdsReduction rule for rescheduling.When an active process is re-leased or terminates,the active process is replaced by the pro-cess.This process allows a release process from the process queue to be scheduled for execution:(R ED-R ESCHEDULE)fds fds Reduction rules for method invocation and return.A method call results in a method activation on the callee’s process queue.As the call is asynchronous there is a delay between the call and its activation,represented by the sleeping future in the configuration. After method lookup,a process is created which binds the methods formal parameters to the actual arguments of the call,sets the local variables of the method body to their default values,and has the body of the method as its list of statements.This process is added to the process queue,and the future changes its mode to active.This mode change prevents multiple bindings of the call.(R ED-B IND)mbody srdefault mid sr oid fds mid oidoid fds mid oidWhen the execution of a process is completed,the return value is stored in the appropriate future in the configuration,as identified by the pseudo-variable of the process.This future changes its mode to indicate that the method has completed.The active process becomes.(R ED-R ETURN)midfds mid oidfds mid oid Reduction rules for merge.Either branch of a merge statement may be selected for initial reduction.(R ED-M ERGE1)fds fds(R ED-M ERGE2)fds fdsWhen one branch of a merge statement completes,the other branch is scheduled:(R ED-M ERGE-S KIP)fds fds Reduction rules for release.Process release is complicated by the merge()operator.If a release occurs within a merge,the other branch of the merge is thefirst candidate for rescheduling —rescheduling is local to a method,whenever possible.If the other branch would also immediately release,then the process is released,after which a suspended process may be rescheduled. Let be a state(mappingfields and local variables to their val-ues).In order to formalize this notion of release,define a predicate enabled on guards,futures,and states which determines whether a guard will not directly release as follows:enabled falseenabledenabled var enabled varenabled mode where mid_mode_ enabled enabled enabledThe predicate is lifted to program statements as follows: enabled enabledenabled enabledenabled enabled enabledenabled enabled enabledenabled true otherwiseNote that the contexts and redexes do not factor an expression uniquely.There is one place where they overlap.Expressions in-volving can sometimes be factored as bothand.A clause is added to the reduction rules for to ensure that evaluates where possi-ble instead of—the difference is that in thefirst case, local rescheduling occurs within a process,whereas in the second case the process is released.The reduction rules for release are:(R ED-M ERGE-R ELEASE1)enabled fdsfdsfds(R ED-M ERGE-R ELEASE2)enabled fdsfdsfds(R ED-R ELEASE)fdsfdsContext and parallel reductions.A reduction applies to a sub-configuration,which is captured by the following reduction rule:(R ED-C ONTEXT)config configconfig config config config42006/10/2Let denote,i.e.,some configuration constisting only offuture objects.The following rule enables futures to be shared between concurrently evaluating configurations,increasing the amount of concurrency expressible in the rules.(R ED-P ARALLEL)config config config configconfig configconfig config config configAs the futures may evolve in both reductions,they need to be recomposed in a consistent way.Let be an idempotent and symmetric function collecting futures from and,which resolves conflicting futures with the same mid as follows:mid mc mid mc mid mc mid mc mid mc mid mcmid mc mid mc mid mcand undefined otherwise.New futures in the reductions will be located in config and config.The rule(R ED-P ARALLEL)allows futures witnessed by one process to be changed by another.This is consistent,as only one process may change the future.2.3Synchronization and Self-callsThe read operation on a future variable is blocking,and may therefore be used to introduce synchronization points in the code;e.g.,with the statements the active process is blocked after making a call to until the call has been completed, resembling a notion of synchronous call.The language naturally supports asynchronous calls to self, ,which create local processes to be executed at some point when the active process is.However synchronizing on local calls is problematic:the statementslead to deadlock.In order to execute a local method the pro-cess needs to be released,as in the asynchronous call sequence.This sequence does not capture a direct transfer of control between the active process and the call to,but enables any other blocked processes in the object to be activated before the call to.Consequently we prefer to un-derstand synchronous self calls,with syntax such as,as an orthogonal language issue which can be adapted from standard approaches to recursive calls by refining our notion of a process either as a stack of calls or by expanding local calls in place.3.TypingThe section presents the static semantics for our language.The type rules for programs,classes,method declarations,and standard statements follow those of Featherweight Java or ClassicJava,and may be found in an Appendix.Emphasis here is on the rules for the particular constructs of the language.Recall from Fig.1that the types of the language are, class names,and.The latter type identifies a future variable of type.The typing environment binds variables to their type and has the following grammar:The rules for the read and polling operations on a future variable and for guards are given as follows:(E XPR-G ET)(E XPR-P OLL)(S TAT-A WAIT)(G UARD-W AIT)In order to specify the well-formedness of runtime configura-tions,the typing environments are extended with type informa-tion concerning object and future identifiers:oid midA process inside an object is well-formed(i.e.,)if its local vari-ables have values matching their declared types,and the statement being executed is well-formed in a typing environment which contains thefields declared in the class of the object.The process is always well-formed.(V ALUE)vv(I DLE)(P ROCESS)A configuration may be an object,a future,or the composition of two configurations.Configurations are well-formed whenever their constituents are well-formed and the objects and futures have unique identifiers.An object is well-formed whenever the values in itsfields have the type declared in the object’s class,and its active process as well as all the blocked processes in its process queue are well-formed inside the object.(O BJECT)oidfields fdsfor eachoid,C fdsThe(delayed)method call stored in a future must be a valid method call to the callee.The type of a future identifier mid must be of the form,where is the return type of the method being called.Finally,the value stored in the future must have the correct type,after the future has completed.(F UTURE)oid mid mtype mmode vmid oid m v mode vThe following collects the identifiers defined in a configuration:cfig cfig cfig cfigoid___oidmid___midThe rule for composing configurations is given as follows:(C ONFIG-J OIN)config configconfig configconfig config3.1Meta-TheoryThe language presented here resembles Java(say,ClassicJava[12]), whose type soundness(at the class,object,and method level)is well understood.Fortunately,the additional concurrency constructs do not significantly complicate the proof of type soundness.Indeed, even the introduction of futures only requires a minor change to the standard progress result.52006/10/2In order to ensure the soundness of the system,futures must behave sensibly.In particular,the behavior of futures is crucial for the(R ED-P ARALLEL)reduction rule and for the proof theory.We define the following relation on futures:oid oidoidNow reconsider the rule(R ED-P ARALLEL),which allows the future shared between two parallel reductions to change in one reduction,though not in the other—enabling a greater degree of concurrency to be captured by the operational semantics.An instance of the rule may beconfig comp config compconfig comp config compconfig config comp config config comp comp wherecomp mid modecomp mid modecomp mid modeIf the configuration config config comp is well-typed,the object identifiers in the configuration are unique,so the object with iden-tifier can only be present in one of the subconfigurations.It fol-lows that comp can only be modified in that subconfiguration,so we must have that either comp comp or comp comp.With-out loss of generality,we may assume the former,and it follows from the definition of then comp comp comp.The only reduction rules which affect the value of a future are:(R ED-C ALL) initializes a future to mode(sleeping);(R ED-B IND)changes a fu-ture’s mode to(active);andfinally(R ED-R ETURN)sets the value of a future and changes its mode to(completed).No operation af-fects the value of a future which is completed.Hence,the following lemma holds for the(R ED-P ARALLEL)rule:L EMMA1.Given the above set-up,comp comp is defined and comp comp comp.A consequence of this lemma is that after a parallel reduction, all the futures which were shared in the two reductions remain valid:i.e.,is never undefined.The definition of is naturally extended to configurations in a pointwise manner:config config if and only if comp comp for all mid config such that comp config,comp config,and comp comp mid.The following property holds for reductions:L EMMA2.If config and config config’,then config config’.Subject reduction can then be established for the language:T HEOREM1.If config and config config,then there exists a such that config’.In order to give a progress theorem,wefirst need to distinguish between expressions which“go wrong”and are excluded by the type system,those which result in an error not detected by the type system,specifically,pointer exceptions,and those which block.The following redexes are error redexes:The following redex is a blocking redex:midA progress property can then be established for the language: T HEOREM2.If config fds and, where is a redex which is neither an error nor a blocking redex,then there exists a reduction involving,namely,config fds config fds’Furthermore,if and_config,then the above statement also holds.4.ExamplesE XAMPLE1.We consider a version of the sieve of Eratosthenes in which each prime number is represented by a concurrent instance of class.Each object checks whether it is a factor of given integers using method.If this is not the case,the integer is passed to the prime number object by a call to the latter’s method,which repeats this test for the next prime number.In a distributed environment,calls to an object from some object may overtake calls from another object.This could have the undesirable effect in our example,as factor division tests may be skipped.For example if is executed after,25may be taken for a prime number. Thus a certain amount of synchronization is required for the prime number sieve to function correctly.In the code below,the sieve is not completely sequentialized,but allows two factorization tests to be performed concurrently.Synchronization is achieved by letting the second computation in a prime number object wait for the completion of the call to the next prime for the previous integer before passing on the present integer to the next prime(if the factorization test for the present integer fails).This is done by introducing a local future against which the call to the sieve method of the next prime is synchronized.E XAMPLE2.To illustrate how futures may be passed between objects,we consider a class which converts a future into an event notification service.The example shows how polling in an object may be delegated and the result returned to a different method of the same object.In the example,the future result from a method call made in method of class is passed to an new instance of.The waits on the future object to obtain its result,before passing the result to the method of the original instance of.Notification may also target a different object of class as in a publish/subscribe service[9],where futures are published and subscribers are notified for every completed computation.62006/10/2。