Question

0

171

Views

Xcode Incorrectly Reporting Swift Access Race Condition

I believe XCode is incorrectly reporting Swift Access Race in my SynchronizedDictionary - or is it?

My SynchronizedDictionary looks like this:

public struct SynchronizedDictionary<K: Hashable, V> {
    private var dictionary = [K: V]()
    private let queue = DispatchQueue(
        label: "SynchronizedDictionary",
        qos: DispatchQoS.userInitiated,
        attributes: [DispatchQueue.Attributes.concurrent]
    )

    public subscript(key: K) -> V? {
        get {
            return queue.sync {
                return self.dictionary[key]
            }
        }
        mutating set {
            queue.sync(flags: .barrier) {
                self.dictionary[key] = newValue
            }
        }
    }
}

The following test code will trigger a "Swift Access Race" issue (when the Thread Sanitizer is turned on for the scheme):

var syncDict = SynchronizedDictionary<String, String>()

let setExpectation = XCTestExpectation(description: "set_expectation")
let getExpectation = XCTestExpectation(description: "get_expectation")

let queue = DispatchQueue(label: "SyncDictTest", qos: .background, attributes: [.concurrent])

queue.async {
    for i in 0...100 {
        syncDict["\(i)"] = "\(i)"
    }
    setExpectation.fulfill()
}

queue.async {
    for i in 0...100 {
        _ = syncDict["\(i)"]
    }
    getExpectation.fulfill()
}

self.wait(for: [setExpectation, getExpectation], timeout: 30)

The Swift Race Access look like this:

I really did not expect there to be an access race condition here, because the SynchronizedDictionary should handle the concurrency.

I can fix the issue by, in the test, wrapping the getting and setting in a DispatchQueue similar to the actual implementation of the SynchronizedDictionary:

let accessQueue = DispatchQueue(
    label: "AccessQueue",
    qos: DispatchQoS.userInitiated,
    attributes: [DispatchQueue.Attributes.concurrent]
)

var syncDict = SynchronizedDictionary<String, String>()

let setExpectation = XCTestExpectation(description: "set_expectation")
let getExpectation = XCTestExpectation(description: "get_expectation")

let queue = DispatchQueue(label: "SyncDictTest", qos: .background, attributes: [.concurrent])

queue.async {
    for i in 0...100 {
        accessQueue.sync(flags: .barrier) {
            syncDict["\(i)"] = "\(i)"
        }
    }
    setExpectation.fulfill()
}

queue.async {
    for i in 0...100 {
        accessQueue.sync {
            _ = syncDict["\(i)"]
        }
    }
    getExpectation.fulfill()
}

self.wait(for: [setExpectation, getExpectation], timeout: 30)

...but that already happens inside the SynchronizedDictionary - so why is Xcode reporting an Access Race Condition? - is Xcode at fault, or am I missing something?

over 4 years ago · Santiago Trujillo

1 answers

Answer question

0

Answer question

Find remote jobs

Accepted Answer · 2022-05-24T17:06:53.527Z

The thread sanitizer reports a Swift access race to the

var syncDict = SynchronizedDictionary<String, String>()

structure, because there is a mutating access (via the subscript setter) at

syncDict["\(i)"] = "\(i)"

from one thread, and a read-only access to the same structure (via the subscript getter) at

_ = syncDict["\(i)"]

from a different thread, without synchronization.

This has nothing to do with conflicting access to the private var dictionary property, or with what happens inside the subscript methods at all. You'll get the same “Swift access race” if you simplify the structure to

public struct SynchronizedDictionary<K: Hashable, V> {
    private let dummy = 1

    public subscript(key: String) -> String {
        get {
            return key
        }
        set {
        }
    }
}

So this is a correct report from the thread sanitizer, not a bug.

A possible solution would be to define a class instead:

public class SynchronizedDictionary<K: Hashable, V> { ... }

That is a reference type and the subscript setter no longer mutates the syncDict variable (which is now a “pointer” into the actual object storage). With that change, your code runs without errors.

0

171

Xcode Incorrectly Reporting Swift Access Race Condition

1 answers

0

Find remote jobs

Andres GPT