On Mar 13, 2012, at 2:09 PM, JongAm Park wrote: > Is there any reason to design threading and UI update model like this?
Yes. Parallel computing with shared state is extremely hard. So hard that I don’t think it’s even well-understood yet, in particular how one can properly test such a system. (See the classic paper “The Problem With Threads”*.) Back in 1998-2000 I was tech lead for Java frameworks at Apple, which mostly involved getting AWT and Swing to run well on Mac OS. It was a very painful task, and one of the biggest problems was thread-safety. Code that started out clean, readable and maintainable turned into a mess once we’d gone through and fixed a seemingly-endless series of deadlock and race-condition bugs. Performance suffered because of all the lock contention. I was very happy to put that problem behind me forever and turn to Cocoa. Parallel processing is of course getting more and more important, but I think the old approach of “let’s spawn lots of threads and have all of them try to access everything at once” is dead. Systems that limit the use of shared state, like the “actor” model used by Erlang and Scala, seem pretty promising. GCD and blocks make it easier to implement that kind of code. So my contention, based on my experience, is that if you have a design where a lot of threads find themselves wanting to access the UI, you should think about redesigning your architecture. —Jens * http://www.eecs.berkeley.edu/Pubs/TechRpts/2006/EECS-2006-1.pdf _______________________________________________ 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
