#concurency

Having dealt with concurrency and data synchronization issues in the past, I’m always interested to hear how other folks approach that problem set. With that in mind I checked out Swift by Sundell Episode #95 “Concurrency orchestration” with special guest Brent Simmons. I usually keep these notes in order of the discussion in the podcast, but I’ve reorganized this time to keep related topics together. 

~~~~~~~~~~

Concurrency

You usually want to be pushing background work onto a serial queue.

Want to stay on main thread unless there’s a really solid reason not to. Write it the ideal way. If you see a blocker, use profiler and see what’s the root cause.

Identify things that need to go in the background and make them self contained (example rss parsing, parsing data and turning into model object). During parsing you shouldn’t be doing anything that could affect the rest of the app. Put the work on a serial queue and callback on the main thread.

The fact that something is on a background thread should not leak. Send the operation to the background queue, then callback at the end. Don’t have the background thread sending notifications or doing other things that leak knowledge that it is background work.

Threading leads to so much uncertainty and problems. Reducing areas of moving back & forth makes your code more resilient.

Try giving structure

Going from main to background to another background can be okay, but consider treating it as a stack and moving data back up rather than cutting straight back to a previous queue/main queue.

Thread safety

Sharing mutable data across threads is setting self up for crashes or data inconsistencies

Databases

serial queue for reads & writes that calls back onto main queue

Keeps changes ordered

Always calling back on main thread

Apple tends to callback on thread work performed on.

URLSession does work on background then calls your callback also on background.

Can lead to data races, or calling UI APIs from background threads.

Need to look out for these and make sure UI work is going back on main queue.

Can write code such that you accept a callback queue but have it default to main so you can choose a different queue if necessary.

Performance problems on main thread

Many developers tend to drop to work to background threads before profiling to know where the issue is coming from.

Not everything can be solved with concurrency. The problem might manifest as a lot time in a function, but a background thread might be a bandaid rather than solving the issue.

Senior developers

Role is to find simpler solutions, find the simplest way to create a performant experience, not complicated code.

Brent Simmons project - NetNewsWire

Open source project. 

Originally Mac only (project started pre-iPhone). Rewritten in 2014. 

Created version of the app using SwiftUI & combine only, did not ship since performance wasn’t where they wanted things to be, but held onto that code. 

They are using a couple pieces of SwiftUI in shipping app, but mostly waiting to fully shift over to SwiftUI

Mac vs phone SwiftUIMac performance noticeably less than on iPhone. large reason chose not to switch over to SwiftUI after investing time was degraded performance on Mac

Anyone can join the open source development of net news wire:

Check the app out

Check out the GitHub

Join the slack group and “work” channel

Talk about what you’re interested in building or ask for a bug to work on

Concurrency for NetNewsWire

objects are never mutable on main

Has a single background queue for database operations

Status objects (read/starred) is reference object created & mutated on a background serial queue

Any thread can say to update the “read” status, but that “read” status is only ever updated on the one synchronized queue.

Reflection

How are you handling threads in your project?

Does your background work callback on background or main?

Is your background thread sending notifications or other things that leak background status?

Typically, when you need to share an updateable variable among threads, synchronization is used. Synchronization among multiple threads used to be achieved using the synchronized keyword and it was based on an object’s monitor. If a thread is not able to acquire an object’s monitor, that thread is suspended and it has to be resumed later. This way of synchronization (suspending and resuming) uses a great deal of system resources. The problem is not in the locking and unlocking mechanism of the monitor lock; rather it is in suspending and resuming the threads.

An atomic variable uses a lock-free synchronization of a single variable. Note that if your program needs to synchronize on more than one shared variable, you still need to use the old synchronization methods. By lock-free synchronization, I mean that multiple threads can access a shared variable safely using no object monitor lock. JDK takes advantage of a hardware instruction called “compare-and-swap" (CAS) to implement the lock-free synchronization for one variable.

CAS is based on three operands: a memory location M, an expected old value O, and a new value N. If the memory location M contains a value O, CAS updates it atomically to N; otherwise, it does not do anything. CAS always returns the current value at the location M that existed before the CAS operation started. The pseudo code for CAS is as follows:

CAS(M, O, N) { currentValueAtM = get the value at Location M; if (currentValueAtM == O) { set value at M to N; } return currentValueAtM; }

The CAS instruction is lock free. It is directly supported in most modern computers’ hardware. However, CAS is not always guaranteed to succeed in a multi-threaded environment. CAS takes an optimistic approach by assuming that there are no other threads updating the value at location M; if the location M contains value O, update it to N; if the value at location M is not O, do not do anything. Therefore, if multiple threads attempt to update the value at location M to different values simultaneously, only one thread will succeed and others will fail.

Atomic variable classes are named like AtomicXxx, and can be used to execute multiple instructions on a single variable atomically without using any lock. Here, Xxx is replaced with different words to indicate different classes that are used for different purposes; for example, the AtomicInteger class is used to represent an int variable, which is supposed to be manipulated atomically. Twelve classes in the Java class library support read-modify-write operations on a single variable atomically.*1

Instances of classes AtomicBoolean, AtomicInteger, AtomicLong, and AtomicReference each provide access and updates to a single variable of the corresponding type. Each class also provides appropriate utility methods for that type. For example, classes AtomicLong and AtomicInteger provide atomic increment methods. One application is to generate sequence numbers, as in:

class Sequencer { private final AtomicLong sequenceNumber = new AtomicLong(0); public long next() { return sequenceNumber.getAndIncrement(); } }

It is straightforward to define new utility functions that, like getAndIncrement, apply a function to a value atomically. For example, given some transformation

long transform(long input)

write your utility method as follows:

long getAndTransform(AtomicLong var) { while (true) { long current = var.get(); long next = transform(current); if (var.compareAndSet(current, next)) return current; // return next; for transformAndGet } }

In addition to classes representing single values, this package contains Updater classes that can be used to obtain compareAndSet operations on any selected volatile field of any selected class. AtomicReferenceFieldUpdater, AtomicIntegerFieldUpdater, and AtomicLongFieldUpdater are reflection-based utilities that provide access to the associated field types. These are mainly of use in atomic data structures in which several volatile fields of the same node (for example, the links of a tree node) are independently subject to atomic updates. These classes enable greater flexibility in how and when to use atomic updates, at the expense of more awkward reflection-based setup, less convenient usage, and weaker guarantees.*2

*1 Beginning Java Language Features By Kishori Sharan