[swift-users] Atomics and Memory Fences in Swift

[Colin Barrett]

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-users/attachments/20170504/47eb9708/attachment.html>