Multithreading on iOS

AGENDA
Multithreading Basics
Interlude: Closures
Multithreading on iOS
Multithreading Challenges

WHY DO WE NEED THREADS?
Listen for User Input
Respond to User Input
Application Code
Time
Application Code
Application Code
…

MULTITHREADING BASICS
The entire program is blocked while one piece of code is running!
@IBAction func downloadButtonPressed(sender: AnyObject) {
downloadData()
updateBusyIndicator()
}
updateBusy
Indicator:
downloadData:
download
Button
Pressed:
Thread 1 (Main Thread)

Long running tasks block our program. The UI
freezes!
Threads allow us to run multiple tasks in parallel!

By using a background thread we can unblock the UI thread!
updateBusy
Indicator:
download
Button
Tapped:
Thread 1 (Main Thread)
Thread 2 (Background Thread)
downloadData:
updateBusy
Indicator:
updateBusy
Indicator:
updateBusy
Indicator:

Application CodeTime
Application Code
…
}Long-running
task
Application Code
Application Code
Main Thread Background Thread

Multithreading works independently of the underlying
hardware architecture
Multiple threads can run on a single core, each thread gets
a certain amount of execution time

Spawning and executing a thread and switching
between threads consumes resources, especially on a
single core system multithreading hurts overall
performance (even though it can improve perceived
performance through responsiveness)
In most UI Frameworks (including UIKit) UI updates are only
possible from the main thread

WHEN TO USE MULTITHREADING
Improve responsiveness of application by performing long
running tasks in background threads
Improve Performance by utilizing multiple cores at once

CLOSURES
Anonymous functions that can capture and modify
variables of their surrounding context
Are reference types; can be passed around in code

MULTITHREADING ON IOS
You can create a new Thread by creating an instance of
NSThread (not recommended)
Most of the time you should be using GCD (Grand Central
Dispatch)

GCD
Abstraction for the concept of threads, instead we think of
diﬀerent queues for our application
GCD determines which queues are mapped to which
threads
Closure based API

GCD MINDSET
Instead of thinking about particular threads, think whether
work should happen on main or background thread
Think about whether certain tasks should be performed
concurrently or sequentially

GCD
dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_BACKGROUND, 0)) {
let data = downloadData()
dispatch_async(dispatch_get_main_queue()) {
updateUI(data)
}
}

GCD
dispatch_sync blocks the current thread until the block is
executed
dispatch_async let’s the current thread continue, executes
the dispatched block some time in the future

SYNCHRONIZATION OF THREADS
Parallel execution of code leads to situations where multiple
threads access the same resources at (almost) the same time
In many cases this is undesirable:
One thread reads an instance of NSMutableArray while another
thread manipulates the same instance (unpredictable result)
Some operations in our applications need to be performed
atomically

Balance:
1000$
1
2
3
-100$
-900$
-200$
Balance:
-200$
1b
2b
3b
Account Balance Update
Account Transaction
Balance:
1000$ 1
-100$
1b
Balance:
900$ 2
-900$
2b
Balance:
0$ 3
-200$
} One atomic
transaction

Most commonly you will use a mutex lock
(mutual exclusion lock) to synchronize code
With a mutex lock you can lock a piece of
code to only be run by one thread at a time
@synchronized(self)
ThreadA
@synchronized(self)
ThreadB
ThreadC
ThreadD
@synchronized(self) {
if ( (self.balance - amount) >= 0) {
self.balance -= amount;
}
}
Obj-C Code - Swift lacks this simple API:

DEADLOCKS
Deadlocks can occur when a thread is waiting for an
event which cannot happen anymore
These situations can occur when more than one lock is
involved
Example:
Thread A has acquired Lock “objectA” and is trying to
acquire additional Lock “objectB”
Thread B has acquired Lock “objectB” and is trying to
acquire additional Lock “objectA”
Try to avoid acquiring multiple locks
@synchronized(objectA)
ThreadA
@synchronized(objectB)
ThreadB

RACE CONDITIONS
Race Conditions are bugs that only occur when multiple threads
access shared resources in a speciﬁc order
For this reason Race Conditions are very hard to debug
Critical shared resources should be protected by synchronization
Debugging threading issues can become almost impossible -
good design upfront is extremely important

SYNCHRONIZATION TOOLS
USED WITH SWIFT

LOCKS
Swift does not (yet) have a mutex lock API like Obj-C has
Developers came up with their own API:
// API Definition
func synced(lock: AnyObject, closure: () -> ()) {
objc_sync_enter(lock)
closure()
objc_sync_exit(lock)
}
// Usage
synced(self) {
println("This is a synchronized closure")
}
Source: http://stackoverﬂow.com/questions/24045895/what-is-the-swift-equivalent-to-objective-cs-synchronized
Usually using a serial 
queue is better than  
using locks!

SERIAL DISPATCH QUEUES
Preferred over locks - has better performance and conveys intention clearer
Serial queue guarantees that all dispatched blocks get executed after each
other - only one running at a time
class Account {
var balance = 0
let accessBankAccountQueue = dispatch_queue_create("com.makeschool.bankaccount", nil)
func withdraw(amount: Int) {
dispatch_sync(accessBankAccountQueue) {
if ( (self.balance - amount) >= 0) {
self.balance -= amount;
}
}
}
}

NSOPERATIONQUEUE
More abstract version of GCD Queue, based on Objective-C objects
(NSOperations) instead of blocks
Provides additional features:
Dependencies between operations
Operation Priorities
Operations can be cancelled
Always performs operations concurrently while respecting dependencies

NSOPERATIONQUEUE
let downloadQueue = NSOperationQueue()
let downloadOperation = NSBlockOperation {
// perform download here
print("downloading")
}
downloadOperation.queuePriority = .Low
let updateDBOperation = NSBlockOperation {
// update DB here
print("update DB")
}
// update DB after download completes
updateDBOperation.addDependency(downloadOperation)
// add operations to queue to get them started
downloadQueue.addOperations([downloadOperation, updateDBOperation], waitUntilFinished: false)

DISPATCH SEMAPHORE
Dispatch semaphores are a ﬂexible way to block one thread until another
thread sends a signal
Also useful to restrict access to ﬁnite resources (provide count > 0 
in semaphore initializer), called counting semaphore
let currentOperationSemaphore = dispatch_semaphore_create(0)
dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_LOW, 0)) {
print("work")
dispatch_semaphore_signal(currentOperationSemaphore)
}
dispatch_semaphore_wait(currentOperationSemaphore, DISPATCH_TIME_FOREVER)
print("done")
}

DISPATCH GROUPS
When you want to create a group of actions and wait until all actions in
that group are completed you can use dispatch groups
let mainQueueGroup = dispatch_group_create()
for (var i = 0; i < 10; i++) {
dispatch_group_async(mainQueueGroup, dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_BACKGROUND, 0)) { [i] in
print("Download Data: (i)")
}
}
dispatch_group_wait(mainQueueGroup, DISPATCH_TIME_FOREVER)
print("All Downloads Completed")
dispatch_group_wait blocks the current thread until all operations in the dispatch group are
completed
Alternatively you can deﬁne a block that shall be called when the group completes by using
dispatch_group_notify

DISPATCH GROUPS
let mainQueueGroup = dispatch_group_create()
for (var i = 0; i < 10; i++) {
dispatch_group_async(mainQueueGroup, dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_BACKGROUND, 0)) { [i] in
print("Download Data: (i)")
}
}
dispatch_group_wait(mainQueueGroup, DISPATCH_TIME_FOREVER)
print("All Downloads Completed")
Example Output:
Download Data: 2
Download Data: 0
Download Data: 3
Download Data: 1
Download Data: 4
Download Data: 5
Download Data: 6
Download Data: 7
Download Data: 8
Download Data: 9
All Downloads Completed

SIDE NOTE: ASYNCHRONOUS
CODE IN PLAYGROUNDS
import Cocoa
import XCPlayground
print("happens later")
}
XCPSetExecutionShouldContinueIndefinitely()
Source: http://stackoverﬂow.com/questions/24058336/how-do-i-run-asynchronous-callbacks-in-playground

SUMMARY
Mostly we use multithreaded code to create non-blocking UIs by executing
long running tasks on a background thread
GCD that uses blocks is our favorite way to implement multithreading on
iOS because it allows the OS to choose the most eﬃcient implementation
Multithreaded code needs to be designed well to avoid race conditions
and deadlocks and to group certain tasks into transactions
Our favorite tools to implement well designed multithreaded code are the
serial dispatch queue and the NSOperationQueue

EXERCISE
Download the Starter Project.
1. Create a non-blocking version of the app that updates the progress label correctly
using GCD
2. Improve the performance of the app by submitting each operation as an individual
block, ensure that the “Completed” message is still displayed correctly
3. Refactor the code to use GCD groups to determine when all tasks have completed
4. Increase the operation count from 20 to 1000 and add buttons to start and cancel
operations (hint: use NSOperationQueue)

REFERENCES
Apple Docs: Swift Closures
Erica Sadun: Capturing References in Closures
Apple Docs: Migrating Away From Threads
Apple Docs: GCD Reference
Blog Post: More than you want to know about @synchronized

Multithreading on iOS

More Related Content

What's hot

Viewers also liked

Similar to Multithreading on iOS

Recently uploaded

Multithreading on iOS