On 22 Feb 2013, at 18:18, Quincey Morris wrote:
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.
Yes, I agree, as soon as it starts to get complicated, ASync Delegate
callbacks start to get out of control and you're left with a giant
mess if you are not careful!
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.
True, but there are ways to avoid this.
-- Threads blocked in a synchronous method can't cancel themselves
or respond to environmental changes like memory pressure until they
return.
True, but you can set a time-out running and if you keep track of
which processes are "waiting" you can wake them up and have them
cancel themselves.
-- 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.
The problem with using Blocks is that on every implementation, I seen
so much identical code that has been cut and pasted. The way around
this is to have the Code Block call a common method, but this then
spreads the code out again. Ironically (or maybe not so), ASync code
with code blocks makes it much easier to convert the ASync Method
into a a Sync method though.
-- 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.
Yes and as I said, you can a turn an ASync method into Sync easily
enough if you want to.
All the Best
Dave
_______________________________________________
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
