UNIVERSITY OF WATERLOO
Faculty of Mathematics
WHY THE ACTOR PATTERN IS THE SOLUTION TO
CONCURRENCY PROBLEMS IN OBJECTIVE-C AND SWIFT
Oath, Inc.
Sunnyvale, California
Prepared by
Shao-Chi (Andy) Liang
2A Computer Science
ID 20649857
Apr 2018 Memorandum
To: WatPD Evaluators
From: Shao-Chi (Andy) Liang
Date: April 14, 2018
RE: Work Term Report: Why the Actor pattern is the solution to concurrency problems in Objective-C and Swift
I have prepared the following report, “Why the Actor pattern is the solution to concurrency problems in Objective-C and Swift”, for my 2A work term report. This is my second report out of the four that the Co-operative Education Program requires for my Bachelor of Computer Science degree; it has not received academic credit.
At the Flurry team at Oath Inc (previously, Yahoo Inc), we are working to improve and create the world’s largest mobile analytics platform and framework that would enhance a developer’s ability to understand its user-base and product usage. This is my second term at this team and my personal responsibilities as a software engineering intern include working on improving the core Flurry iOS framework, which is widely used globally my many developers and companies. This report is an in-depth analysis on the implementation of concurrency models for iOS (namely, in the Objective-C and Swift programming language), and how the Actor pattern is a superior option that is used by Flurry and many Oath products.
The Faculty of Mathematics requests that you evaluate this report for command of topic and technical content and analysis. I would like to thank my peers and also supervisors at the University of Waterloo for providing suggestions in this report and about potential improvements. I have not received further assistance.
Thank you for your assistance in preparing this report.
Andy Liang TABLE OF CONTENTS
Executive Summary iii
1.0 – Introduction 1
2.0 – Analysis 2
2.1 – 2
3.0 – Conclusion 9
References 10
Image Sources 12
Executive Summary
The report entitled “Why the Actor pattern is the solution to concurrency problems in Objective-C and Swift” aims to describe and highlight the current implementations of different concurrency models that are currently deployed and used by developers around the world in the two programming languages and why the Actor pattern is the superior option for programmers developing for the iOS or macOS platform.
This report draws research on the many different patterns that are currently available, highlighting their pros and cons, and why certain developers would prefer one model over the other ones. Furthermore, the report shows analysis on how beginner or junior developers may have trouble understanding and implementing these concurrency models leading to many concurrency related bugs in their products. Through analysis of the data, it can be shown that the Actor pattern can solve many problems that tend to obstruct a developer’s implementation, including deadlocks, race conditions.
It is concluded that the Actor pattern is a clear solution to solve many problems with concurrency that plague developers, and that learning this model for use in their iOS or macOS projects would be beneficial over other concurrency model implementations that they may have been using. 1.0 – Introduction
When the first commercial home computers became available about forty years ago, it was just the beginning of the age of technology where resources such as storage space and memory was very limited. Fast forward forty years, computers nowadays have up to a thousand times more memory than the very first computers less than half a century ago, and have processors over a thousand times faster than those in the very first computers. As technology improved, so did the number of cores in a computer processor. Rather than simply increasing just the speed of the the processor itself, the processors gained additional cores to smoothly handle additional tasks simultaneously. However, the programs developers write must be able to utilize these capabilities, as many had previously been designed for single core usage.
As hardware technology expanded to multiple cores, new software and systems were introduced to take advantage of the faster processing power. To take advantage of multi-core processors when developing programs–especially one as complex as, for example, iTunes– may be a very challenging task, especially for junior or beginning programmers. To develop software is to compile lines of logic statements for the computer to understand and compute; utilizing extra processing power and cores require the necessary implementations in the programs themselves to support these improvements.
With that said, this means that the developers themselves must have the necessary skills and knowledge in concurrency programming. The system provides the developers the necessary API (application programming interface), a set of protocols and tools for building application software, the developers need to know how best to use them to improve their own applications.
2.0 – Analysis
To truly understand why the Actor pattern is a potential solution to many concurrency problems in Objective-C and Swift, we must first clearly define what concurrency is, the different concurrency models, and how they differ from one another.
2.1 – What is Concurrent Programming?
Due to the nature and scope of concurrency in programming, we will only discuss the subjects of concurrent programming in terms of iOS and macOS, namely, in the programming languages of Objective-C and Swift. Concurrency is the ability to run tasks or parts of the program in parallel, which can improve the overall speed of execution of the program itself. For example, suppose we have a program that reads a file from the system and downloads data from a remote server that is displayed on screen to the user. Without concurrency, downloading data would need to wait for the file to be read from the system before it can begin, which would wait until its completion before anything is shown on screen. With concurrency, we can load the file from disk and download data from the internet independently and simultaneously, and displaying any information on screen to the user when either is complete. This would greatly increase the load time of the program and improve the user experience itself.
2.2 – Ways to implement concurrency in iOS and macOS
Concurrency can be very effective but it is not magic. The system or the program itself does not know how to split tasks that can run concurrently or in serial, or how to prioritize certain tasks over other ones without any developer implementation. There are several system options offered by Apple’s SDK (Software Development Kit), including Grand Central Dispatch (GCD), NSOperationQueue, or pthread, with libDispatch being the most popular and widely used option. These APIs allow the developers to scale their programs for concurrency purposes without having the burden of interacting with the low level system themselves.
With GCD, we introduce the concept of queues. A dispatch queue allows the developer to add a task onto a certain queue that will execute the task, and provides benefits such as “a straightforward and simple programming interface”, memory efficiency, scalability, and the “speed of tuned assembly” (REFERENCE HERE). As with any queue concept, tasks added into the queue are essentially run in a first-in, first-out order. Dispatch queues can be either serial or concurrent, that is, tasks in the queue can either run one at a time, or possibly concurrently, while maintaining its execution order.
On the other hand, NSOperationQueue is a more concurrent approach at dispatch queues. Rather than following the standard first-in, first-out order of a dispatch queue, task in an operation queue take in “other factors into account when determining the execution order of tasks” (REFERENCE HERE), this includes priority tags or whether a task depends on another one’s completion before running, which allows the developer to configure a more complex execution order graph for chained tasks.
Lastly, we have pthreads, or POSIX Threads, an execution model that exists independently from languages and is part of the underlying system itself, whereas NSOperationQueue and libDispatch are Objective-C and Swift features. Threads exist at the most basic level of the operating system, and pthreads allows a developer to write code for any operation system that complies with the standard and expect it to work. However, using threads can be very overwhelming for developers, especially junior or even intermediate, and is precisely why GCD, which is built on top of threads, was created in the first place; why re-invent the wheel when Apple has done it for you!
2.3 – Challenges in Concurrent Programming
When you start to write code in a concurrent manner, you lose the run-time guarantee of data protection and may run into deadlocks and race conditions. It becomes increasingly difficult to ensure the tasks you are executing are not conflicting with another from a different class. Problems can arise in very non-deterministic ways, which explains why debugging is more difficult in concurrent programs.
The 1995 Mars Pathfinder mission is a well-known example in concurrency programming problems that almost costed the mission itself! The Pathfinder was plagued by a bug that would cause “occasional total system resets, resulting in loss of meteorological data” due to a priority-inversion problem, which came from an “infrequent, low-priority, data-collection task that launched a high priority bus-management task to publish its data that locked out other bus accesses” that would “eventually [set] off a watchdog timer that would…reset the entire system” (REFERENCE HERE).
Many problems in concurrency come from access of shared resources through multiple threads; a resource is a property or an object within the memory, such a file reference, network data, etc. When multiple threads start to access the same resource concurrently, there would be a potential conflict which can cause memory corruption and possibly a crash in the application. This is called a race condition, and it can happy when two or more separate threads are accessing the same resource, where both are trying to read and write values to the resource concurrently and causing problems due to the time the value is read by the first thread and when it is written.
Another prominent problem that arise is a dead lock. Dead locks occur when multiple threads are waiting on each other to finish their tasks and eventually get stuck because neither can run without the other’s completion. While using GCD, it is highly possible for someone who is of beginner or intermediate level to unknowingly create dead locks in their program. GCD is very efficient, but it is not magic. With these potential problems in GCD in mind, we can take a look at the actor model and how it can easily solve these problems that may arise in concurrent programming.
2.4 – What is the Actor model and what does it solve?
The actor model is a concurrency model that isolates concurrent entities (classes) that communicate using asynchronous messages and do not share any mutable states. This allows the actor model to avoid very common concurrency problems such as race conditions and deadlocks.
Mutual Exclusion
Deadlocks 3.0 – Conclusion
The complexity of concurrent programming can be very high for junior or intermediate programmers writing for the macOS and iOS platform. While Apple provides sufficient system APIs to make our lives easier in writing concurrent code, it remains very difficult and without the right concurrent model to build the foundations of your program, it can get really messy really fast and things can get out of hands really easily.
The macOS and iOS SDK has come very far in making the lives of developers easier. With the introduction of Grand Central Dispatch, it removed the need to manually manage threads from the developer’s hand and moved it to the system level. However, there still exists many risks that lesser experienced developers may improperly use the APIs and cause problems that are already very difficult to debug, such as dead locks and race conditions, in their programs.
Using the actor pattern to model their concurrency code, the programmer can explicitly create a boundary between their classes and ensure that no boundaries will be crossed through the message-delivery system from the actor model, thus reducing the risks of any race conditions due to the lack of shared resources. On the other hand, a correct implementation of the actor model is built on top of an asynchronous system, which will removing the possibility of dead locks in programs.
Concurrency is an extremely efficient and powerful tool to take advantage of the latest and greatest technology in modern multicore CPUs that exist in our laptops, tablets, and phones. The key is to follow a concrete concurrency model that is as simple as possible, i.e. the actor model, to reduce the chances of mistake so that all potential concurrency problems and bugs will just disappear. It’s that simple! References
Markowitz, M. C. (1998, March 2). Alienating software bugs. EDN, 43(5), 31. Retrieved from http://link.galegroup.com.proxy.lib.uwaterloo.ca/apps/doc/A20457755/AONE?u=uniwater&sid=AONE&xid=0d924b19
Image Sources