[swift-dev] Questions about ARC

[John McCall]

> On Nov 30, 2016, at 11:58 AM, Alexis <abeingessner at apple.com> wrote:
>> On Nov 30, 2016, at 12:41 PM, John McCall via swift-dev <swift-dev at swift.org <mailto:swift-dev at swift.org>> wrote:
>> 
>> When we say that we don't have a concurrency model, we mean that (1) we aren't providing a more complete language solution than the options available to C programmers and (2) like C pre-C11/C++11, we have not yet formalized a memory model for concurrency that provides formal guarantees about what accesses are guaranteed to not conflict if they do race.  (For example, we are unlikely to guarantee that accesses to different properties of a struct can occur in parallel, but we may choose to make that guarantee for different properties of a class.)
>> 
> 
> I’d actually been intending to ask about this. Is there any reason why the lowest level won’t just be a fairly vanilla copy-paste of the C11 concurrency model. That is, there’s non-atomic/relaxed/acquire/release/seqcst loads and stores, and all the happens-before graph stuff that comes along with it. I imagine doing anything else would be fairly challenging for LLVM?

Well, that would be the basic approach, but you still have to define what accesses are non-interfering.  C, for example, says that ordinary fields can be independently accessed without racing, but bitfields generally cannot.  That rule (among others) prohibits certain layout optimizations that we'd like to still do in Swift, e.g. packing Bool properties together.

John.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-dev/attachments/20161130/f087ec99/attachment.html>