Depricated Method

Ya, the Swift 2.2 code was calling OSAtomicAdd32 in an application.

The C language dialect is set to Compiler Default.

I have some other C/C++ code that I wrote a wrapper for. ( some c code that used var args ) I can add the code there. Figure Swift is not going to like the C static in the given example.

Thanks again eskimo!

Figure Swift is not going to like the C static in the given example.

Keep in mind that Swift does not currently define a memory model and, as such, it’s hard to reason about atomics in Swift. Using a simple atomic counter should be fine but you can run into serious problems on weak memory machines (like ARM) if you rely on the relative ordering of memory accesses.

This is very much like C in the pre-C11 days (-:

Until this gets sorted out my advice is to use the higher-level locking APIs (pthreads, GCD, NSLock) rather than atomics. In fact, that’s my advice in general. I’ve seen a lot of folks use atomics because they think that it will help performance; this isn’t necessarily true and, regardless, it runs counter to the standard performance advice (which is write clear code, measure it, optimise from there).

Share and Enjoy
—
Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware

let myEmail = "eskimo" + "1" + "@apple.com"

Hmm, in my original Objective-C code, there was a fix for getting around some touch screen issues.

Prior, I used to have an atomic property in Objective-C. ( not specifying nonatomic in the property ) The main thread via a UIPanGestureRecognizer target action would set the value of this property. Another thread created via dispatch async that is continuosly processing would read the atomic property and its produced results would then get consumed by a display link callback.

Seemed to work well until ( if I can recall ) iOS 8 and the new pressure sensitive touch screen. Then there were delays/pauses when the non ui thread ( not main thread ) would see the change. It would then cause a skip in what was presented in the display link down stream. So, the user interaction became not as responsive. Also, I switched up the qos priorty on the processing thread too to .userInteractive -- seemed to turbo charge things. That is when I replaced the property with OSAtomicAdd32 and the issue went away.

Maybe I should revisit with the property again in Swift 3.0. Things seem to be running well in Swift 3 now with the atomic fetch .mm wrapper .

Regardless of what else you do, you should run your app under the thread sanitiser. See WWDC 2016 Session 412 Thread Sanitizer and Static Analysis for details.

Share and Enjoy
—
Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware

let myEmail = "eskimo" + "1" + "@apple.com"