Delft University of Technology Software Engineering Research Group Technical Report Series A Study and Toolkit for Asynchronous Programming in C# Semih Okur, David L. Hartveld, Danny Dig and Arie van Deursen Report TUD-SERG-2013-016 SERG TUD-SERG-2013-016 Published, produced and distributed by: Software Engineering Research Group Department of Software Technology Faculty of Electrical Engineering, Mathematics and Computer Science Delft University of Technology Mekelweg 4 2628 CD Delft The Netherlands ISSN 1872-5392 Software Engineering Research Group Technical Reports: http://www.se.ewi.tudelft.nl/techreports/ For more information about the Software Engineering Research Group: http://www.se.ewi.tudelft.nl/ Note: This paper is currently under review. c copyright 2013, by the authors of this report. Software Engineering Research Group, Department of Software Technology, Faculty of Electrical Engineering, Mathematics and Computer Science, Delft Uni- versity of Technology. All rights reserved. No part of this series may be reproduced in any form or by any means without prior written permission of the authors. A Study and Toolkit for Asynchronous Programming in C# A Study and Toolkit for Asynchronous Programming in C# Semih Okur1, David L. Hartveld2, Danny Dig3, Arie van Deursen2 1University of Illinois 2Delft University of Technology 3Oregon State University [email protected] [email protected] [email protected] [email protected] ABSTRACT invert the control flow, are awkward, and obfuscate the in- Asynchronous programming is in demand today, because tent of the original synchronous code [38]. responsiveness is increasingly important on all modern de- Recently, major languages (F# [38], C# and Visual Ba- vices. Yet, we know little about how developers use asyn- sic [8] and Scala [7]) introduced async constructs that re- chronous programming in practice. Without such knowl- semble the straightforward coding style of traditional syn- edge, developers, researchers, language and library design- chronous code. Thus, they recognize asynchronous program- ers, and tool vendors can make wrong assumptions. ming as a first-class citizen. We present the first study that analyzes the usage of Yet, we know little about how developers use asynchronous asynchronous programming in a large experiment. We an- programming and specifically the new async constructs in alyzed 1378 open source Windows Phone (WP) apps, com- practice. Without such knowledge, other developers cannot prising 12M SLOC, produced by 3376 developers. Using this educate themselves about the state of the practice, language data, we answer 2 research questions about use and mis- and library designers are unaware of any misuse, researchers use of asynchronous constructs. Inspired by these findings, make wrong assumptions, and tool vendors do not provide we developed (i) Asyncifier, an automated refactoring tool the tools that developers really need. This knowledge is also that converts callback-based asynchronous code to the new important as a guide to designers of other major languages async/await; (ii) Corrector, a tool that finds and corrects (e.g., Java) planning to support similar constructs. Hence, common misuses of async/await. Our empirical evaluation asynchronous programming deserves first-class citizenship in shows that these tools are (i) applicable and (ii) efficient. empirical research and tool support, too. Developers accepted 313 patches generated by our tools. We present the first study that analyzes the usage of asyn- chronous libraries and new language constructs, async/await in a large experiment. We analyzed 1378 open source Win- dows Phone (WP) apps, comprising 12M SLOC, produced 1. INTRODUCTION by 3376 developers. While all our empirical analysis and User interfaces are usually designed around the use of a tools directly apply to any platform app written in C# (e.g., single user interface (UI) event thread [16, 17, 24, 25]: every desktop, console, web, tablet), in this paper we focus on the operation that modifies UI state is executed as an event on Windows Phone platform. that thread. The UI “freezes” when it cannot respond to in- We focus on WP apps because we expect to find many ex- put, or when it cannot be redrawn. It is recommended that emplars of asynchronous programming, given that respon- long-running CPU-bound or blocking I/O operations exe- siveness is critical. Mobile apps can easily be unresponsive cute asynchronously so that the application (app) continues because mobile devices have limited resources and have high to respond to UI events. latency (excessive network accesses). With the immediacy Asynchronous programming is in demand today because of touch-based UIs, even small hiccups in responsiveness are responsiveness is increasingly important on all modern de- more obvious and jarring than when using a mouse or key- vices: desktop, mobile, or web apps. Therefore, major pro- board. Some sluggishness might motivate the user to unin- gramming languages have APIs that support non-blocking, stall the app, and possibly submit negative comments in the asynchronous operations (e.g., to access the web, or for file app store [37]. Moreover, mobile apps are becoming increas- operations). While these APIs make asynchronous program- ingly more important. According to Gartner, by 2016 more ming possible, they do not make it easy. than 300 billion apps will be downloaded annually [18]. Asynchronous APIs rely on callbacks. However, callbacks The goal of this paper is twofold. First, we obtain a deep understanding of the problems around asynchronous pro- gramming. Second, we present a toolkit (2 tools) to address exactly these problems. To this end, we investigate 1378 WP Permission to make digital or hard copies of all or part of this work for apps through tools and by hand, focussing on the following personal or classroom use is granted without fee provided that copies are research questions: not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, to RQ1: How do developers use asynchronous programming? republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. RQ2: To what extent do developers misuse async/await? ICSE ’14 Hyderabad, India Copyright 20XX ACM X-XXXXX-XX-X/XX/XX ...$15.00. We found that developersSE heavily useRG callback-based asyn- 1 TUD-SERG-2013-016 1 A Study and Toolkit for Asynchronous Programming in C# chronous idioms. However, Microsoft no longer officially rec- Code 1 Synchronous example ommends these asynchronous idioms [30] and has started to 1 void Button_Click(...) { replace them with new idioms in new libraries (e.g., WinRT). 2 string contents = GetFromUrl(url) Developers need to refactor callback-based idioms to new id- 3 textBox.Text = contents; ioms that can take advantage of the async/await language 4 } 5 string GetFromUrl(string url) { constructs. The changes that the refactoring requires are 6 WebRequest request = WebRequest.Create(url); non-trivial, though. For instance, developers have to inspect 7 WebResponse response = request.GetResponse(); deep call graphs. Furthermore, they need to be extra careful 8 Stream stream = response.GetResponseStream(); 9 return stream.ReadAsString(); to preserve the exception-handling. Thus, we implemented 10 } the refactoring as an automated tool, Asyncifier. We also found that nearly half of WP8 apps have started to use the 9-month-old async/await keywords. However, busy-wait for completion of the operations. That frees the developers misuse async/await in various ways. We de- UI event thread to respond to user input, or redraw the UI: fine misuse as anti-patterns, which hurt performance and the user will experience the UI to be responsive. might cause serious problems like deadlocks. For instance, CPU-bound operations can be executed asynchronously we found that 14% of methods that use (the expensive) by (i) explicitly creating threads, or (ii) by reusing a thread async/await do this unnecessarily, 19% of methods do not from the thread pool. follow an important good practice [22], 1 out of 5 apps miss I/O operations are more complicated to offload asyn- opportunities in async methods to increase asynchronicity, chronously. The naive approach would be to just start and developers (almost) always unnecessarily capture con- another thread to run the synchronous operation asyn- text, hurting performance. Thus, we implemented a trans- chronously, using the same mechanics as used for CPU- formation tool, Corrector, that finds and corrects the mis- bound code. However, that would still block the new thread, used async/await. which consumes significant resources, hurting scalability. This paper makes the following contributions: The solution is to use asynchronous APIs provided by the Empirical Study: To the best of our knowledge, this is the platform. The .NET framework mainly provides two models first large-scale empirical study to answer questions about for asynchronous programming: (1) the Asynchronous Pro- asynchronous programming and new language constructs, gramming Model (APM), that uses callbacks, and (2) the async/await, that will be available soon in other major pro- Task Asynchronous Pattern (TAP), that uses Tasks, which gramming languages. We present implications of our find- are similar to the concept of futures found in many other ings from the perspective of four main audiences: develop- languages such as Java, Scala or Python. ers, language and library designers, researchers, and tool vendors. 2.1 Asynchronous Programming Model Toolkit: We implemented the analysis and transformation APM, the Asynchronous Programming Model, was part algorithms to address the challenges (Asyncifier and Cor- of the first version of the .NET framework, and has been rector). in existence for 10 years. APM asynchronous operations Evaluation: We evaluated our tools by using the code cor- are started with a Begin method invocation. The result is pus and applied the tools hundreds of times. We show that obtained with an End method invocation. In Code listing 2, our tools are highly applicable and efficient.