Transparency and Asynchronous Method Invocation Pierre Vignéras GIK Institute of Engineering Sciences and Technology Topi, N.W.F.P, 23460 Pakistan. pierre@giki.edu.pk Abstract. This article focuses on transparency in the context of asynchronous method invocation. It describes two solutions available to provide full-transparency: where asynchronism is entirely masked to the developer. The main contribution of this paper is to clearly present the drawbacks of this ap- proach: exception handling and developer consciousness are two problems inherent to full-transparency that makes it at least, hard to use, at worst, useless. This paper defends explicit asynchronous method invocation and proposes semi-transparency: almost all the complexity of asynchronism is masked to the developer but the asynchronism itself. keywords: transparency, asynchronous method invocation, concurrency 1 Introduction Transparency is an abstract notion already used in many contexts. Intuitively, its goal is to hide the com- plexity of an aspect – usually a non functional one – to developers. Java/RMI [16] is a good example of transparency used to hide the complexity of the remote aspect. The syntax of a remote method invocation is almost identical as a local one. The only difference is the fact that remote methods may throw a checked exception (an instance of the class java.rmi.RemoteException or of one of its subclass). Anyway, the semantic of such a call is rather different than in the local case: since parameters are marshaled, the remote target of the call gets either copy or references of each original parameters depending on some of their characteristics (primitive type, serializable, implementing the java.rmi.Remote interface). This behavior is also used for the result transmission. As seen by the success of the Java/RMI framework, and despite the existence of many works that try to enhance it [13,15,10,17], this example clearly shows that transparency of the remote aspect eases the making of distributed applications. Distributed programming has thus clearly been simplified thanks to transparency. Is it also true in the context of concurrent programming? Concurrency will probably be one of the major concern for developers in the next decade. Whereas SMP architectures are quite common today, next-generation processors (CMP, SMT, VMT) [1] will provide lots of low-level threads to the operating system. So, concurrency will be almost anywhere, in low-level architectures, in operating systems and in high level languages such as Java and C# which already provide a thread API to express concurrency in object oriented applications. Asynchronous method invocation is another paradigm that allows the expression of concurrency. It extends very well the standard synchronous method invocation paradigm and also extends naturally to the remote case as remote method invocation does. This paper focuses on transparency in the context of asynchronous method invocation. Note that the Java language has been used in our study, but many issues described in this paper will also be found in any other object oriented language. Furthermore, some solutions described in this paper is already available in the Mandala project [18]. This paper is organized as follow: section 2 deals with concurrency in the asynchronous method invoca- tion paradigm. Section 3 presents full-transparency, and two solutions for its implementation. The reasons why this mechanism should be avoided are also explained in this section. We propose an alternative in section 4. We finally conclude in section 5 along with some perspectives. 2 Dealing with Concurrency Since we are focusing on transparency, we distinguish the mechanism that provides transparency and the one that provides concurrency. For the latter, many abstractions may be used such as active objects [11], actors [2,3], separates [14], active containers [7,6], or asynchronous references [19].