Re: [Q] Why is the threading and UI updating designed to be done only on a main thread?
Re: [Q] Why is the threading and UI updating designed to be done only on a main thread?
- Subject: Re: [Q] Why is the threading and UI updating designed to be done only on a main thread?
- From: Per Bull Holmen <email@hidden>
- Date: Thu, 15 Mar 2012 12:03:48 +0100
Den 22:09 14. mars 2012 skrev Wade Tregaskis <email@hidden> følgende:
>> I don't like the idea of a multithreaded aproach by default, because as a general rule, you
>> should not make your application multithreaded unless you have a good
>> reason.
>
> a) The reality is that Cocoa already exposes you to a lot of concurrency and asynchronisity, and is only going to do much more so in future. That said, there are limits to what can be done here (especially with dispatch queues; the way GCD paradigms interact with callback patterns is far from seamless).
This is really not an argument at all. That there is already
concurrency and asynchronicity doesn't even resemble a rationale to
introduce more.
> b) This convenientional wisdom is, in my humble opinion, antiquated. It's just the reality today that multi-threaded performance scales better than single-threaded performance. It has been that way for nearly a decade, I'd say. You may disregard that as irrelevant to your app XYZ because any single core today is good enough for it, but just look at the introduction of the iPhone as an example of how single-threaded performance can drop very abruptly, and how you eventually got more cores but not much of a core boost.
>
> And aside from performance, there are many other factors such as latency, responsiveness etc that are intertwined with concurrency (in the sense that dispatch queues, background threads, etc target all the issues simultaneously) which make it wise to get away from a serial world view, even if you don't otherwise pro-actively introduce concurrency.
>
> I am almost certainly on the edge of the bell curve, having spent many years now working on performance tools and HPC, but I've noticed the curve is catching up to me. To those riding the wave, I can promise you this: parallel programming really isn't that hard.
While all these points are very good, I disagree with the conclusion
because I believe in the wisdom: Keep simple things simple. I'm
currently working on a CoreAudio application that does use multiple
threads, with different priorities. It certainly benefits a great deal
from multithreading. Still I must say that having one thread per
window, or one thread per document, would be very counterproductive in
my case. Therefore, my point is not to always avoid threads, but use
it where appropriate, where needed, and in a way that really DOES
really increase scalability, responsiveness etc. instead of relying on
some framework-provided model that is only assumed to do so.
The one thing I do not understand is, how come you can't just
implement the threading model that you find most productive for the
task, on top of the core that receives events in the main thread? This
can't be hard in most cases, and seems to fit better with the MVC
approach in most cases: It is the views that receive events, and they
do truly receive them sequentially. It is your models that may need to
do things concurrently, not your views. If you need to draw from
multiple threads, this can be done with the framework as it is.
You mention how the computer world has evolved towards making
concurrency more useful than before. I agree with what you are saying,
but remember that we MAY also move towards new concepts and
abstractions that make todays concept of multithreading an antiquated
way of achieving parallelism. For example, multithreading is not an
ideal way to exploit multiple processor cores. This is what GCD tries
to remedy. Whether it does achieve its goal I don't know. But if the
whole framework is modelled around an outdated concept, you have a
bigger problem than if it's just each application that is.
Per
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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:
This email sent to email@hidden