> On Dec 4, 2016, at 4:53 PM, Andrew Trick via swift-users
> <swift-users@swift.org> wrote:
>
>
>> On Nov 30, 2016, at 5:40 AM, Anders Ha via swift-users
>> <swift-users@swift.org <mailto:swift-users@swift.org>> wrote:
>>
>> Hi guys
>>
>> I have recently started adopting lock-free atomics with memory fences, but
>> it seems Swift at this moment does not have any native instruments.
>>
>> Then I read a thread in the Apple Developer Forum
>> (https://forums.developer.apple.com/thread/49334
>> <https://forums.developer.apple.com/thread/49334>), which an Apple staff
>> claimed that all imported atomic operations are "not guaranteed to be
>> atomic". But for my tests with all optimizations enabled (-Owholemodule and
>> -O), the OSAtomic primitives and stdatomic fences do not seem going wild.
>>
>> Is these `atomic_*` and `OSAtomic*` primitives really unsafe in Swift as
>> claimed? It doesn't seem like the Swift compiler would reorder memory
>> accesses around a C function call that it wouldn't be able to see through.
>
> Did you get an answer to this? I’m not sure what led you to believe the
> primitives are unsafe in Swift. Importing them doesn’t change their semantics.
If you apply them to memory you allocated manually with malloc/free on
UnsafeMutablePointer's allocation methods, then yeah, they should work as they
do in C. That's the safest way to use these functions today. Passing a Swift
`var` inout to one of these functions does not guarantee that accesses to that
var will maintain atomicity, since there may be bridging or reabstracting
conversions happening under the hood.
-Joe
_______________________________________________
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users
