It is part of the language model that this is safe, so clearly we have to get it right. See also SR-6543.

Then we have to fix the implementation of array and insert a release fence (or a release memory operation on the reference count).

Note that if queue.dispatch has the fence semantics then we are fine. But I am not assuming this because then we would not be relying on array to give us the race freedom. What I am asking is that assume that dispatch does not have fence semantics: is there a language level race or not? If there is no language level race then we have a problem.

The programmer can rely on race freedom on the array buffer because it is semantically part of the array's value. An array has the same semantics as any struct w.r.t. races.

queue.async would need to have a memory fence, otherwise you wouldn't be able to pass any (by-value) data into the closure.

Arnold and I discussed this some in person, and I think we boiled it down to these three examples:

func test() {
  var copy = 0
  spawnThreadWithoutBarrier {
    waitForConditionVariableWithoutBarrier()
    print(copy) // clearly a race
  }
  copy = 5
  signalConditionVariableWithoutBarrier()
}

func test() {
  var g = [0]
  g[0] = 1
  let copy = g
  spawnThreadWithoutBarrier {
    waitForConditionVariableWithoutBarrier()
    print(copy[0]) // race on [0], but not just that (see below)
  }
  signalConditionVariableWithoutBarrier()
}

func test() {
  var g = 42
  var copy = g // This allocates a box and then writes into it
  spawnThreadWithoutBarrier {
    waitForConditionVariableWithoutBarrier()
    print(copy) // STILL A RACE on the storage for 'copy' - may observe it uninitialized!
  }
  signalConditionVariableWithoutBarrier()
}

That is, this isn't about Array specifically; it's about closure captures. The situation does get worse with CoW types (i.e. the second example has two races), but that's not the fundamental scaryness here. However, the point about DispatchQueue.async providing a memory barrier anyway is a good one—most concurrency utilities that operate in terms of closures probably won't run into this in practice.

(cc @devincoughlin as well, for previous discussions of both exclusivity and "value types are safe")

cc phabouzit (JIRA User) for Dispatch insight

Comment by Pierre Habouzit (JIRA)

This:
spawnThreadWithoutBarrier
Or this:
waitForConditionVariableWithoutBarrier
Is just a bug. don't do that.

On any sane platform that I know of, spawning a thread has barriers, condition variables are supposed to be used with a mutex that have the right barriers etc..

Dispatch e.g. for dispatch_async:

• uses a store-release when enqueing a continuation

• relies on the underlying consume ordering and dependencies from the continuation address on dequeue

I don't think Swift should protect against utterly broken synchronization primitives that are used for data synchronization but do not provide the most basic barriers. these are broken.

:-) That's fair. In that case, we should be okay. We won't ever have a race on the initial value that gets captured by a closure because that closure somehow has to make it onto another thread (barrier), and then any other races are at least explainable to people. And catchable by TSan.

If this becomes relevant again in some "system-level Swift" effort, well, they can just take extra care in whatever bizarre situation they have using closures across threads without barriers.

Comment by Pierre Habouzit (JIRA)

Even at the "system" level, people have to be mindful of data synchronization themselves, else you have to pessimize for concurrent use and your runtime would have to store-release about everything which is a broken model.

1. Swift should not provide unsafe sync primitive that can be used as locks and are missing barriers

2. People writing their own sync primitive, need to know what they're doing, and if it synches data, it implies having proper visibility.

3. Profit?