Hacker News Reader

Comment by pmjordan | Hacker News Reader

I wonder how many apps in the app store that use multithreading will suddenly break a lot more frequently because of the second core.[1] Rare, freak crashes and glitches could suddenly become unusably frequent. Maybe all apps submitted with SDK < 4.4 (or whatever) will be pinned to one CPU?

[1] most race conditions will only trigger on a uniprocessor system if preempted, which is fairly unlikely if the racy data accesses are close together.

View on HN

Apple pretty heavily promotes using their concurrency frameworks (GCD, dispatch queues, etc.) that don't require the direct creation of threads by application code [1]. Do you think many applications ignore that and use threads on iOS anyway?

[1] http://developer.apple.com/library/ios/iPad/#documentation/G...

That doesn't really change anything. GCD still uses a thread-based concurrency model, and it's no more or less affected by race conditions than pthreads.

Also GCD is relatively new to iOS, and not the only concurrency API in Cocoa, so yes many apps will still be using (and will continue to use) traditional threads.

GCD is an abstraction that uses queues to communicate work items between pools of worker threads. It has much in common with the actor model in this regard. It doesn't immunize the programmer against race conditions, but it certainly does make them easier to avoid than using pthreads directly.

Unfortunately, work queues aren't a great abstraction for serialisisg access to a shared resource. Given that all iOS devices so far have had a single CPU core, most uses of threading will have been for things like network I/O, audio, or running larger computations in a non-UI-thread, rather than dispatching work items to many CPUs.

Furthermore, GCD has only been around since iOS 4.0, so if your app needs to be compatible to 3.x, you can't use it.

> Maybe all apps submitted with SDK < 4.4 (or whatever)

SDK < iOS5, likely, if they decide to play it safe (or some kind of attribute in the bundle). I highly doubt Apple is going to fork iOS again for no reason at all, 4.3 has yet to be released and iOS5 is 4-5 months away tops.

I don't know that much about programming, but OS X has always supported SMP and multi-core CPU's, and Cocoa also supports it fine.

Right, but it's extremely difficult to get concurrency right at the application level. Anything that works usually works by chance, and changing the hardware that a multithreaded program runs on is a great way to find out how you fucked up the implementation.

Right now, it's likely that a lot of bugs are not showing themselves regularly, so nobody has bothered running any diagnostic tools (Helgrind, etc.)

I agree with you that people are really bad at concurrency, but I disagree that it's that hard once you get used to it.

Once you deal with one large deep difficult highly concurrent project, you get used to the idea that when there are threads and mutexes involved you have to think REALLY HARD about how it should work, and you can't rely on just trying something and testing it like you can with normal code. And if you do that, you can get threads to work pretty reliably, not just by chance.

My thoughts on threads boil down to: they're a tool for library authors. Using them in applications is ... misguided. Use an event loop instead.

I feel it's too harsh to downvote you (so I didn't), but you've pretty much admitted that you don't have enough information to speculate - perhaps you shouldn't. It's not about system software supporting threads; it's about user code not being thread-safe in the presence of hardware parallelism. There are some multi-threading bugs that never show up without it.

Reply on news.ycombinator.com