Apple's description of reference and value types with multiple threads

5 Solutions Collect From Internet About “Apple's description of reference and value types with multiple threads”

As others have pointed out, reference types always pass a pointer to the object, which is ideal where you want a “shared, mutable state” (as that document you referenced said). Clearly, though, if you’re mutating/accessing a reference type across multiple threads, make sure to synchronize your access to it (via a dedicated serial queue, the reader-writer pattern, locks, etc.).

Value types are a little more complicated, though. Yes, as the others have pointed out, if you pass a value type as a parameter to a method that then does something on another thread, you’re essentially working with a copy of that value type (Josh’s note regarding the copy-on-write, notwithstanding). This ensures the integrity of that object passed to the method. That’s fine (and has been sufficiently covered by the other answers here).

But it gets more complicated when you are dealing with closures. Consider, for example, the following:

struct Person {
    var firstName: String
    var lastName: String
}

var person = Person(firstName: "Rob", lastName: "Ryan")

DispatchQueue.global().async {
    Thread.sleep(forTimeInterval: 1)
    print("1: \(person)")
}

person.firstName = "Rachel"
Thread.sleep(forTimeInterval: 2)
person.lastName = "Moore"
print("2: \(person)")

Obviously, you wouldn’t generally sleep, but I’m doing this to illustrate the point: Namely, even though we’re dealing with a value type and multiple threads, the person you reference in the closure is the same instance as you’re dealing with on the main thread (or whatever thread this was running on), not a copy of it. If you’re dealing with a mutable object, that’s not thread-safe.

I’ve contrived this example to illustrate this point, where the print statement inside the closure above will report “Rachel Ryan”, effectively showing the state of the Person value type in an inconsistent state.

With closures using value types, if you want to enjoy value semantics, you have to change that async call to use a separate variable:

let separatePerson = person
queue.async {
    Thread.sleep(forTimeInterval: 1)
    print("1: \(separatePerson)")
}

Or, even easier, use a “capture list”, which indicates what value type variables should be captured by the closure:

queue.async { [person] in
    Thread.sleep(forTimeInterval: 1)
    print("1: \(person)")
}

With either of these examples, you’re now enjoying value semantics, copying the object, and the print statement will correctly report “Rob Ryan” even though the original person object is being mutated on another thread.

So, if you are dealing with value types and closures, value types can be shared across threads unless you explicitly use capture list (or something equivalent) in order to enjoy value semantics (i.e. copying the object as needed).

Yes, references are shared if multiple threads use them; that’s exactly the problem. All threads refer to the same actual data in memory. They then require synchronization mechanisms to ensure that the separate threads’ reads and writes don’t conflict. Those mechanisms have costs in code complexity and in performance.

Instances of value types are not shared: every thread gets its own copy.* That means that every thread can read and write to its instance without having to worry about what other threads are doing.


*With the standard copy-on-write exception for Swift stdlib types: the actual copy is only performed if the data are mutated.

That’s confusingly worded.

Value Types: The data will be used in code across multiple threads.

By this, I believe that they mean it’s useful when you want many threads to read from your data. This is because you know that whenever you give a new thread a copy of your data, you don’t subject any other copies to the risk of unexpected mutation from other threads.

Using value types in such a context, where you don’t need shared mutable state, allows you to avoid many classes of bugs (race conditions, dead lock, live lock, etc.) that come from dealing with reference types.

Reference Types: You want to create shared, mutable state

Only reference types can be shared between threads, by having two threads each retain their own reference to a shared instance.

Apple suggests using a value type when the data will be used across multiple threads to avoid using a shared instance, rather than promoting it.

When you provide your threads with an object of value type, each thread would get its own copy, which in turn lets you not worry about synchronization.

Generally, you should prefer making your value type immutable (although Swift provides a mechanism for you to code mutating functions). When you do that, you have no synchronization problems, even with reference types.

Value Types: The data will be used in code across multiple threads.

The data will not change across the threads once assigned. No worries to other threads since each thread would have its own copy.

Reference Types: You want to create shared, mutable state

The data may change by any of the threads which would affect the other threads as well since its of type reference(ie. pointing to same data in memory).