• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: [Q] Why is the threading and UI updating designed to be done only on a main thread?
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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: Jens Alfke <email@hidden>
  • Date: Tue, 13 Mar 2012 14:35:29 -0700

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 (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


References: 
 >[Q] Why is the threading and UI updating designed to be done only on a main thread? (From: JongAm Park <email@hidden>)

  • Prev by Date: Re: Undomanager for custom object?
  • Next by Date: Re: [Q] Why is the threading and UI updating designed to be done only on a main thread?
  • Previous by thread: [Q] Why is the threading and UI updating designed to be done only on a main thread?
  • Next by thread: Re: [Q] Why is the threading and UI updating designed to be done only on a main thread?
  • Index(es):
    • Date
    • Thread