<div dir="ltr">I haven&#39;t used this in production, but this repository looks pretty promising. It&#39;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 &lt;<a href="mailto:swift-users@swift.org">swift-users@swift.org</a>&gt; wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
&gt; On Apr 25, 2017, at 1:08 PM, Shawn Erickson &lt;<a href="mailto:shawnce@gmail.com" target="_blank">shawnce@gmail.com</a>&gt; wrote:<br>
&gt;<br>
&gt;<br>
&gt; On Mon, Dec 5, 2016 at 9:28 AM Joe Groff via swift-users &lt;<a href="mailto:swift-users@swift.org" target="_blank">swift-users@swift.org</a>&gt; wrote:<br>
&gt;<br>
&gt;&gt; On Dec 4, 2016, at 4:53 PM, Andrew Trick via swift-users &lt;<a href="mailto:swift-users@swift.org" target="_blank">swift-users@swift.org</a>&gt; wrote:<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt;&gt; On Nov 30, 2016, at 5:40 AM, Anders Ha via swift-users &lt;<a href="mailto:swift-users@swift.org" target="_blank">swift-users@swift.org</a>&gt; wrote:<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; Hi guys<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; 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>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; 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 &quot;not guaranteed to be atomic&quot;. But for my tests with all optimizations enabled (-Owholemodule and -O), the OSAtomic primitives and stdatomic fences do not seem going wild.<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; Is these `atomic_*` and `OSAtomic*` primitives really unsafe in Swift as claimed? It doesn&#39;t seem like the Swift compiler would reorder memory accesses around a C function call that it wouldn&#39;t be able to see through.<br>
&gt;&gt;<br>
&gt;&gt; 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>
&gt;<br>
&gt; If you apply them to memory you allocated manually with malloc/free on UnsafeMutablePointer&#39;s allocation methods, then yeah, they should work as they do in C. That&#39;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>
&gt;<br>
&gt; -Joe<br>
&gt;<br>
&gt; Is the following in the ball park of being correct (going back over some old code we have)...<br>
&gt;<br>
&gt; public struct AtomicBool {<br>
&gt;<br>
&gt;     private static let bitLocation: UInt32 = 0<br>
&gt;     private static let trueValue: UInt8 = 0x80<br>
&gt;     private static let falseValue: UInt8 = 0x00<br>
&gt;<br>
&gt;     private let value = UnsafeMutablePointer&lt;UInt8&gt;.allocate(capacity: 1) // TODO - leaking right? How to deal with that in a struct situation...?<br>
&gt;     public var onSet: ((_ old: Bool, _ new: Bool) -&gt; ())?<br>
&gt;<br>
&gt;     public init(_ intialValue: Bool = false) {<br>
&gt;         value.initialize(to: intialValue ? AtomicBool.trueValue : AtomicBool.falseValue)<br>
&gt;         onSet = nil<br>
&gt;     }<br>
&gt;<br>
&gt;     public init(_ intialValue: Bool = false, onSet: ((_ old: Bool, _ new: Bool) -&gt; ())?) {<br>
&gt;         value.initialize(to: intialValue ? AtomicBool.trueValue : AtomicBool.falseValue)<br>
&gt;         self.onSet = onSet<br>
&gt;     }<br>
&gt;<br>
&gt;     public mutating func set(_ newValue: Bool) {<br>
&gt;         _ = getAndSet(newValue)<br>
&gt;     }<br>
&gt;<br>
&gt;     public mutating func getAndSet(_ newValue: Bool) -&gt; Bool {<br>
&gt;         let oldValue: Bool<br>
&gt;         if newValue {<br>
&gt;             oldValue = Darwin.OSAtomicTestAndSetBarrier(AtomicBool.bitLocation, value)<br>
&gt;         }<br>
&gt;         else {<br>
&gt;             oldValue = Darwin.OSAtomicTestAndClearBarrier(AtomicBool.bitLocation, value)<br>
&gt;         }<br>
&gt;<br>
&gt;         onSet?(oldValue, newValue)<br>
&gt;         return oldValue<br>
&gt;     }<br>
&gt;<br>
&gt;     public func get() -&gt; Bool { // TODO - document the lazy &quot;safety&quot; aspect of get<br>
&gt;         return value.pointee != AtomicBool.falseValue<br>
&gt;     }<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>