Rss

We were already dead before the chip even shrank

Interesting questions are floating around about what changes iOS developers need to make, given the introduction of dual-core on the iPad 2, particularly in terms of threading. One question that came up is whether we should still default to nonatomic properties, as multiple threads could run through the getters and setters at the same time.

My opinion, at this time, and as expressed in a devforums thread, is that any code that will break under dual-core is already broken under single-core. The problem is not that two threads can execute simultaneously with dual-core, it’s that you have code sections that aren’t thread-safe and need to be. Dual-core will, at most, encounter the problem more frequently.

On iOS, we tend to make all properties involving UIKit nonatomic, meaning they do not synchronize access to the getter or setter (i.e., enforce a one-thread-at-a-time rule), for performance reasons. The reason for this really doesn’t have to do with the nature of atomicity, per se, it’s that any time you touch UIKit, you must do so from the main thread. Declaring nonatomic is just a consequence of this: the property should only be called from one thread, main, so you shouldn’t need to worry about coordinating multi-threaded access to the property. In other words, your thread management issues lie elsewhere, not with the atomicity of the property, so you can still declare these properties as nonatomic.

On the other hand, properties that aren’t related to UIKit may need to be atomic. If you think you’ll only ever call it from a single thread, fine, but if you’re not consciously enforcing that and just getting lucky, then you may be just one block, NSOperation, or callback on a mystery thread away from a nasty race condition.

In the first version of our iPhone SDK Development book, Bill and I all but ignored threading — NSOperation doesn’t even appear in the index — because we kept things simple enough that everything could be assumed to be running on the main thread. In the new world of blocks and Grand Central Dispatch, this is no longer a safe assumption, and we’d probably need to engage threading issues early. A greater awareness of threads and a willingness to use NSOperation or other threading approaches should help with performance on the new device too.

Comments (3)

  1. Joel Bernstein

    Does the iOS Simulator take advantage of multiple cores when available? If so, there’s a good chance that most applications have already been tested in a dual-core environment.

  2. Joel: I wondered about that myself, and came to the hypothesis that the simulator might not be able to specifically control how many cores it uses, since it itself is a Mac app using similar APIs, and GCD operates at a high level of abstraction, above CPUs and even above threads.

    A Google search shows a discussion of this is already underway at Stack Overflow, with two good answers: 1. the simulator compiles for Intel, not ARM, so any behavior you see there is not necessarily indicative of how threads and cores will behave on the device, 2. if you create a bunch of threads and keep them busy, the simulator will indeed pound away on whatever cores are available to it.

    When I get back to the computer (I’m on the iPad at the standing desk right now), it might be fun to duplicate that #2 code and see if the simulator will saturate all 8 of my cores.

  3. ZPedro

    Sorry to react so late, but I have important information on the matter. First, dual-core actually does bring new issues that aren’t seen at all in a preemptive single core environment: memory ordering issues. I wrote a blog post explaining the issue. So it’s not always true that code that breaks on the iPad 2 was already broken in the first place on, say, the iPad. Second, and worse, the fact most apps were tested with the simulator in an x86 dual-core environment has no bearing on whether they will run fine on a dual-core iPad 2 (as a Joel suggested), since ARM allows quite more reordering than x86 does. Let me repeat that because it is important: x86 SMP (and single-core ARM even more so) makes guarantees that ARM SMP does not provide, and existing code may rely on these guarantees (and thus break only on the iPad 2).

    However, I do agree that atomicity is orthogonal with dual-core and there is no reason to declare properties atomic more just because of the iPad 2.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.