On Feb 22, 2013, at 08:32 , Dave <d...@looktowindward.com> wrote: > As long as you are not running on the main thread there is no real difference > between a Sync or ASync operation as far as any of the issues you mention > above are concerned.
You're correct that, at some level, using synchronous methods on a background thread is an equivalent to using async methods on the main thread (or any other thread, for that matter). > The question is you have two black box methods that do the same thing, one > has Sync in it's name the other has ASync in it's name. Given everything else > is equal (which is is in this case), which one would you choose and why? The main advantage of synchronous methods on a background thread is simplicity and/or conciseness of the code. In some cases, that can be a big enough "win" to choose this approach over the other. Comparatively, the main advantage of async methods is their modest resource requirements, which means they may scale better. For example, you could likely perform thousands of (individually slow) network accesses simultaneously this way, while you really wouldn't want to create thousands of threads to do the same thing with sync calls. (That's an artificial and impractical example, of course.) However, there's a whole boatload of disadvantages to using the sync calls which are purely situational, and can only be evaluated in a particular app design context. For example: -- Very often, your background thread will need to trigger updates to the UI, and it must "switch" to the main thread to do this. That may introduce asynchronous behavior into the background thread, which in turn may subvert its entire approach. -- Threads blocked in a synchronous method can't cancel themselves or respond to environmental changes like memory pressure until they return. -- Since blocks were introduced, the frameworks have rapidly embraced blocks-based asynchronous patterns. That means that some of the most recent, capable and convenient APIs are async-only. -- An interesting example I came across recently is AVFoundation, where there is API for loading asset object properties asynchronously. The documentation notes that you can do it synchronously in a background thread in OS X if you want, but you should not try doing that on iOS because you're likely to have your app killed by the OS for being non-responsive. So, there's something of a trend -- currently -- towards asynchronicity. My suggestion would be to use the synchronous background approach if/when that truly simplifies the implementation, but when your task becomes more complex switch over to the better supported async approach. _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
