> On Nov 30, 2016, at 11:58 AM, Alexis <abeingess...@apple.com> wrote:
>> On Nov 30, 2016, at 12:41 PM, John McCall via swift-dev <swift-dev@swift.org
>> <mailto:swift-dev@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.
_______________________________________________
swift-dev mailing list
swift-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-dev
