[swift-users] Atomics and Memory Fences in Swift

[Guillaume Lessard]

It works now, but it's not correct. I wish there were a correct way available.

Guillaume Lessard

> On May 3, 2017, at 21:30, Colin Barrett via swift-users <swift-users at swift.org> wrote:
> 
> I haven't used this in production, but this repository looks pretty promising. It's more or less just wrapping up the clang atomic intrinsics into a Swift package.
> 
> https://github.com/glessard/swift-atomics
> 
> -Colin
> 
>> On Mon, May 1, 2017 at 12:43 PM Joe Groff via swift-users <swift-users at swift.org> wrote:
>> 
>> > On Apr 25, 2017, at 1:08 PM, Shawn Erickson <shawnce at gmail.com> wrote:
>> >
>> >
>> > On Mon, Dec 5, 2016 at 9:28 AM Joe Groff via swift-users <swift-users at swift.org> wrote:
>> >
>> >> On Dec 4, 2016, at 4:53 PM, Andrew Trick via swift-users <swift-users at swift.org> wrote:
>> >>
>> >>
>> >>> On Nov 30, 2016, at 5:40 AM, Anders Ha via swift-users <swift-users at 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), 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
>> >
>> > Is the following in the ball park of being correct (going back over some old code we have)...
>> >
>> > public struct AtomicBool {
>> >
>> >     private static let bitLocation: UInt32 = 0
>> >     private static let trueValue: UInt8 = 0x80
>> >     private static let falseValue: UInt8 = 0x00
>> >
>> >     private let value = UnsafeMutablePointer<UInt8>.allocate(capacity: 1) // TODO - leaking right? How to deal with that in a struct situation...?
>> >     public var onSet: ((_ old: Bool, _ new: Bool) -> ())?
>> >
>> >     public init(_ intialValue: Bool = false) {
>> >         value.initialize(to: intialValue ? AtomicBool.trueValue : AtomicBool.falseValue)
>> >         onSet = nil
>> >     }
>> >
>> >     public init(_ intialValue: Bool = false, onSet: ((_ old: Bool, _ new: Bool) -> ())?) {
>> >         value.initialize(to: intialValue ? AtomicBool.trueValue : AtomicBool.falseValue)
>> >         self.onSet = onSet
>> >     }
>> >
>> >     public mutating func set(_ newValue: Bool) {
>> >         _ = getAndSet(newValue)
>> >     }
>> >
>> >     public mutating func getAndSet(_ newValue: Bool) -> Bool {
>> >         let oldValue: Bool
>> >         if newValue {
>> >             oldValue = Darwin.OSAtomicTestAndSetBarrier(AtomicBool.bitLocation, value)
>> >         }
>> >         else {
>> >             oldValue = Darwin.OSAtomicTestAndClearBarrier(AtomicBool.bitLocation, value)
>> >         }
>> >
>> >         onSet?(oldValue, newValue)
>> >         return oldValue
>> >     }
>> >
>> >     public func get() -> Bool { // TODO - document the lazy "safety" aspect of get
>> >         return value.pointee != AtomicBool.falseValue
>> >     }
>> 
>> That looks OK. It might be better to provide an allocate/deallocate or with { ... } interface instead of burying the allocate call in the initializer since the user will need to handle the deallocation of the buffer at some point.
>> 
>> -Joe
>> _______________________________________________
>> swift-users mailing list
>> swift-users at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-users
> _______________________________________________
> swift-users mailing list
> swift-users at swift.org
> https://lists.swift.org/mailman/listinfo/swift-users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-users/attachments/20170504/ad18fe15/attachment.html>