<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div>It works now, but it's not correct. I wish there were a correct way available.<br><br>Guillaume Lessard</div><div><br>On May 3, 2017, at 21:30, Colin Barrett via swift-users <<a href="mailto:swift-users@swift.org">swift-users@swift.org</a>> wrote:<br><br></div><blockquote type="cite"><div><div dir="ltr">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.<div><br></div><div><a href="https://github.com/glessard/swift-atomics">https://github.com/glessard/swift-atomics</a><br></div><div><br></div><div>-Colin</div></div><br><div class="gmail_quote"><div dir="ltr">On Mon, May 1, 2017 at 12:43 PM Joe Groff via swift-users <<a href="mailto:swift-users@swift.org">swift-users@swift.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
> On Apr 25, 2017, at 1:08 PM, Shawn Erickson <<a href="mailto:shawnce@gmail.com" target="_blank">shawnce@gmail.com</a>> wrote:<br>
><br>
><br>
> On Mon, Dec 5, 2016 at 9:28 AM Joe Groff via swift-users <<a href="mailto:swift-users@swift.org" target="_blank">swift-users@swift.org</a>> wrote:<br>
><br>
>> On Dec 4, 2016, at 4:53 PM, Andrew Trick via swift-users <<a href="mailto:swift-users@swift.org" target="_blank">swift-users@swift.org</a>> wrote:<br>
>><br>
>><br>
>>> On Nov 30, 2016, at 5:40 AM, Anders Ha via swift-users <<a href="mailto:swift-users@swift.org" target="_blank">swift-users@swift.org</a>> wrote:<br>
>>><br>
>>> Hi guys<br>
>>><br>
>>> I have recently started adopting lock-free atomics with memory fences, but it seems Swift at this moment does not have any native instruments.<br>
>>><br>
>>> Then I read a thread in the Apple Developer Forum (<a href="https://forums.developer.apple.com/thread/49334" rel="noreferrer" target="_blank">https://forums.developer.apple.com/thread/49334</a>), 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.<br>
>>><br>
>>> 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.<br>
>><br>
>> 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.<br>
><br>
> 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.<br>
><br>
> -Joe<br>
><br>
> Is the following in the ball park of being correct (going back over some old code we have)...<br>
><br>
> public struct AtomicBool {<br>
><br>
> private static let bitLocation: UInt32 = 0<br>
> private static let trueValue: UInt8 = 0x80<br>
> private static let falseValue: UInt8 = 0x00<br>
><br>
> private let value = UnsafeMutablePointer<UInt8>.allocate(capacity: 1) // TODO - leaking right? How to deal with that in a struct situation...?<br>
> public var onSet: ((_ old: Bool, _ new: Bool) -> ())?<br>
><br>
> public init(_ intialValue: Bool = false) {<br>
> value.initialize(to: intialValue ? AtomicBool.trueValue : AtomicBool.falseValue)<br>
> onSet = nil<br>
> }<br>
><br>
> public init(_ intialValue: Bool = false, onSet: ((_ old: Bool, _ new: Bool) -> ())?) {<br>
> value.initialize(to: intialValue ? AtomicBool.trueValue : AtomicBool.falseValue)<br>
> self.onSet = onSet<br>
> }<br>
><br>
> public mutating func set(_ newValue: Bool) {<br>
> _ = getAndSet(newValue)<br>
> }<br>
><br>
> public mutating func getAndSet(_ newValue: Bool) -> Bool {<br>
> let oldValue: Bool<br>
> if newValue {<br>
> oldValue = Darwin.OSAtomicTestAndSetBarrier(AtomicBool.bitLocation, value)<br>
> }<br>
> else {<br>
> oldValue = Darwin.OSAtomicTestAndClearBarrier(AtomicBool.bitLocation, value)<br>
> }<br>
><br>
> onSet?(oldValue, newValue)<br>
> return oldValue<br>
> }<br>
><br>
> public func get() -> Bool { // TODO - document the lazy "safety" aspect of get<br>
> return value.pointee != AtomicBool.falseValue<br>
> }<br>
<br>
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.<br>
<br>
-Joe<br>
_______________________________________________<br>
swift-users mailing list<br>
<a href="mailto:swift-users@swift.org" target="_blank">swift-users@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-users" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-users</a><br>
</blockquote></div>
</div></blockquote><blockquote type="cite"><div><span>_______________________________________________</span><br><span>swift-users mailing list</span><br><span><a href="mailto:swift-users@swift.org">swift-users@swift.org</a></span><br><span><a href="https://lists.swift.org/mailman/listinfo/swift-users">https://lists.swift.org/mailman/listinfo/swift-users</a></span><br></div></blockquote></body></html>