Den 22:09 14. mars 2012 skrev Wade Tregaskis <wadesli...@mac.com> 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 (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
