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 > <[email protected]> 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 >> <[email protected]> wrote: >> >> > On Apr 25, 2017, at 1:08 PM, Shawn Erickson <[email protected]> wrote: >> > >> > >> > On Mon, Dec 5, 2016 at 9:28 AM Joe Groff via swift-users >> > <[email protected]> wrote: >> > >> >> On Dec 4, 2016, at 4:53 PM, Andrew Trick via swift-users >> >> <[email protected]> wrote: >> >> >> >> >> >>> On Nov 30, 2016, at 5:40 AM, Anders Ha via swift-users >> >>> <[email protected]> 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 >> [email protected] >> https://lists.swift.org/mailman/listinfo/swift-users > _______________________________________________ > swift-users mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-users
_______________________________________________ swift-users mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-users
