5 Replies
      Latest reply: Sep 16, 2016 1:01 AM by eskimo RSS
      macnib Level 1 Level 1 (10 points)

        Upgrading code to Swift 3.0/ Xcode 8 .

         

        I see there is a depricated method: OSAtomicAdd32 . The note in the header says to look in stdatomic.h for atomic_fetch_add_explicit. If I do a search its in:

         

        ./Developer/Toolchains/Swift_2.3.xctoolchain/System/Library/PrivateFrameworks/LLDB.framework/Versions/A/Resources/Clang/include/stdatomic.h

        ./Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/clang/8.0.0/include/stdatomic.h

        ./Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/swift-migrator/swift/clang/include/stdatomic.h

        ./SharedFrameworks/LLDB.framework/Versions/A/Resources/Clang/include/stdatomic.h

         

        Its not in /Applications/Xcode.app/Contents/Developer/Platforms so is this not part of the iOS SDK? ( I guess so lol )

         

        If I try to type it in the editor, its not auto completing. No luck there. If I search the Xcode documentation there are no results in Xcode 8.0 (8A218a) GM.

         

        Any hints/clues what to import or link to would be appreciated.

        • Re: Depricated Method
          eskimo Apple Staff Apple Staff (7,005 points)

          OSAtomic has been deprecated in favour of C language atomics, as introduced by the C11 standard.  To can use them from C and Objective-C with code like this:

          static _Atomic(int) i;
          
          oldValue = atomic_fetch_add_explicit(&i, 1, memory_order_relaxed);
          

          As this is a standard C construct, there’s lots of references on the ’net showing the details.

          There’s also a (much nicer) C++ equivalent, if you’re that way inclined.

          It wasn’t clear from reading your post whether you’re trying to do this from Objective-C or Swift.  The situation with atomics from Swift is somewhat trickier.

          Share and Enjoy

          Quinn “The Eskimo!”
          Apple Developer Relations, Developer Technical Support, Core OS/Hardware
          let myEmail = "eskimo" + "1" + "@apple.com"

            • Re: Depricated Method
              macnib Level 1 Level 1 (10 points)

              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!

                • Re: Depricated Method
                  eskimo Apple Staff Apple Staff (7,005 points)

                  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"

                    • Re: Depricated Method
                      macnib Level 1 Level 1 (10 points)

                      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 .