• 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: NSOutlineView threading problem
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: NSOutlineView threading problem


  • Subject: Re: NSOutlineView threading problem
  • From: Jens Alfke <email@hidden>
  • Date: Mon, 16 Jun 2008 08:36:52 -0700


On 15 Jun '08, at 8:05 PM, David wrote:

Threading is hard for me to comprehend in the objective-c world. In Java,
threading is powerful and relatively simple to implement with simple
relatively consistent rules and many classes which are thread safe.

I used to be the tech lead for Java toolkits at Apple — my team primarily worked on implementing AWT and Swing on OS 9 and later Carbon. Threading was an absolute bloody nightmare. Developers would call into AWT from any thread they liked, so everything we implemented had to be completely thread-safe, and interact well with the threading of both the shared (java.*) classes and the underlying OS. During each development cycle we had continual problems with apps failing for various reasons relating to threading, and by the time we got each release stable, our code that had started off clean and modular became encrusted with all sorts of complexity and warts due to lock interdependencies, avoiding race conditions, and the like.


By the time I left the Java team I never wanted to touch another thread again. I moved on to Cocoa and really liked the much saner programming model where threads have minimal interconnections, mostly by message-passing. And this isn't unique to Cocoa — it resembles the 'Agent' design pattern that's been used in many highly-parallel distributed systems. From what I've gleaned so far (just from the gutter press) it sounds like Apple's new "Grand Central" infrastructure in Snow Leopard is something like this, allowing developers to divide processing into large numbers of small components that communicate by messaging.

In my current view, having multiple threads manipulating the same object is a failure of encapsulation, on the same level as having different modules touching the same global variables.

Every time this topic comes up, I link to this article, "The Problem With Threads":
http://www.computer.org/portal/site/computer/menuitem.5d61c1d591162e4b0ef1bd108bcd45f3/index.jsp?path=computer/homepage/0506&file=cover.xml&xsl=article.xsl
It's an academic take on these issues, which concludes that multithreading is intractable and needs to be replaced by new designs that better handle large-scale concurrency. (And it's far from the only thing I've read espousing this viewpoint.) It includes a terrifying story about a large Java server that failed due to a race condition, four years after it had been considered to be bug-free.


—Jens

Attachment: smime.p7s
Description: S/MIME cryptographic signature

_______________________________________________

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: 
 >NSOutlineView threading problem (From: David <email@hidden>)
 >Re: NSOutlineView threading problem (From: David <email@hidden>)
 >Re: NSOutlineView threading problem (From: Bill Bumgarner <email@hidden>)
 >Re: NSOutlineView threading problem (From: David <email@hidden>)

  • Prev by Date: Re: XML-RPC call using Cocoa Frameworks
  • Next by Date: awakeFromNib
  • Previous by thread: Re: NSOutlineView threading problem
  • Next by thread: NSTextField "setStringValue" method - deallocates?
  • Index(es):
    • Date
    • Thread