Swift - 设置变量属性并发或多线程安全吗？

Question

As I know setting a variable property when using concurrency or multithreading is not safe but I can't produce a crash with below code.

class Node {
    var data = 0
}

var node = Node()
let concurrentQueue = DispatchQueue(label: "queue", attributes: .concurrent)

for i in 0...1000 {
    concurrentQueue.async {
        node.data = i    // Should get crash at this line
    }
}

UPDATE1

Thanks @MartinR for pointing out in his comment.

Enable the “Thread Sanitizer” and it'll report an error immediately.

UPDATE2

The code got EXC_BAD_ACCESS KERN_INVALID_ADDRESS crash if changing data to reference type. It doesn't always happen but sometimes it will. For example:

class Data {}

class Node {
    var data = Data()    // Use reference type instead of value type
}

var node = Node()
let concurrentQueue = DispatchQueue(label: "queue", attributes: .concurrent)

for i in 0...1000 {
    concurrentQueue.async {
        node.data = Data()    // EXC_BAD_ACCESS KERN_INVALID_ADDRESS
    }
}

This behavior also happens in Objective-C. Setting object property concurrently will cause crash. But with primitive type, the crash will not happen.

Questions

• Does setting value type property concurrently will produce a crash?
• If it doesn't produce a crash, what is the difference between setting value type property and setting reference type property?

It's perfect if anyone can also explain why setting reference type property concurrently will produce a crash.

Answer 1

First off

Class value are stored in heap memory while struct/enum value are stored in stack memory and compiler will try to allocate those memory at compile time (according to my first ref and many online answer). You can check using this code:

class MemTest {}
class Node {
    var data = MemTest()
}
let node = Node()
let concurrentQueue = DispatchQueue(label: "queue", attributes: .concurrent)

for index in 0...100000 {
concurrentQueue.async {
    node.data = MemTest()
    withUnsafePointer(to: &node.data) {
        print("Node data @ \($0)")
    }
    withUnsafePointer(to: node.data) {
        print("Node data value no. \(index) @ \($0)")
    }
}

How to: run 2 time and check memory address for value changed time 500, switch MemTest between class and struct will show the difference. Struct will show the same while class will show different address between each time. So changing value type is just like changing address but the the memory blocks will not be restored while changing reference type is not just changing address but also restore and allocate new memory blocks which will cause the program to break.

Secondly

But if running first code block of @trungduc with withUnsafePointer, it will show us that the index var of for loop is allocated on the go and in the heap memory, so why is that? As mentioned before, compiler will only try to allocate the mem if the value type is calculable at compile time. If the they are not calculable, the value will be allocated in heap memory and stay there till the end of scope (according to my second ref). So may be the explanation here is the system will restored the allocated stack after everything is done - end of scope (This I'm not very sure). So in this case the code will not produce a crash as we know. My conclusion, the reference type variable's mem will be allocated and restored with no restriction in this case whereas value type variable's mem will be allocated and removed only after the system enter and exit a the scope which contains said variable

Thanks

• @Gokhan Topcu for Check section "Memory Management"
• @Bruno Rocha for Check section "Heap Allocated Value Types"

Some words

My answer is not very solid and might have lots of grammar and spelling error. All update are appreciated. Thanks in advance

Update

For the part I'm not very sure: variable index was copied to a new memory address with operator = so it doesn't matter where the scope end, stack will be released after for loop After some digging, in @trungduc's code, with reference type variable, it will do 3 things:

1. Allocate new memory for class Data
2. Reduce reference to old Data stored in node.data , even free old Data if it's no longer referenced
3. Point node.data to new Data

While for value type it will do 1 thing only:

1. Point node.data to Integer in stack memory The major difference is in step 2 where there is a chance the old Data memory is restored There are possibilities where this scenario will happen with reference type

________Task 1________|________Task 2________
Allocate new Data #1  |
                      |Allocate new Data #2
Load pointer to old   |
Data                  |
Reduce reference count|
to old Data           |
                      |Load pointer to old
                      |Data
Free old Data         |
                      |Reduce reference count
                      |to old Data (!)
                      |Free old Data (!)
Reference new Data #1 |
                      |Reference new Data #2

while with value type, this will happen

________Task 1________|________Task 2________
Reference to Integer 1|
                      |Reference to Integer 2

In the first case we will have various alternative scenarios but in most case, we get a segmentation fault because thread 2 tries to dereference that pointer after thread 1 free it. There might be other issues like memory leaking as we notice, thread 2 might not reduce reference count to Data #1 correctly Whereas in second case, it's just changing the pointer.

Note

In second case, it will never cause crash on Intel CPU but not guaranteed on other CPUs as well because many CPUs do not promise that doing this will not cause a crash.

Answer 2

Non-atomic doesn't mean that app will crash if multiple threads are using the shared resource.

Atomic Properties

Defining a property as atomic will guarantee that a valid value will be returned. Notice that valid does not always mean correct.

This also does not mean that atomic properties are thread safe. Different threads can attempt to write and read a the same time. One of two values will be returned — the value before the change or the value of the change

Non-Atomic Properties

Non atomic properties has no guarantee regarding the returned value. It can be the correct value, a partially written value or even some garbage value.

It simply means that the final value will not be consistent. You won't know which thread will update the value last.

You can refer the link for more clarification on this.