3 ms·
Apple pretty heavily promotes using their concurrency frameworks (GCD, dispatch queues, etc.) that don't require the direct creation of threads by application c
by mryall 16y ago
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/General/Conceptual/ConcurrencyProgrammingGuide/Introduction/Introduction.html%23//apple_ref/doc/uid/TP40008091 http://developer.apple.com/library/ios/iPad/#documentation/G...
- alextgordon 16y agoThat 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.
- rbarooah 16y agoGCD 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.
- pmjordan 16y agoUnfortunately, 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.