• 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: Preventing beach balls
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Preventing beach balls


  • Subject: Re: Preventing beach balls
  • From: Chris Hanson <email@hidden>
  • Date: Sun, 18 Feb 2007 22:53:04 -0800

On Feb 18, 2007, at 5:59 PM, email@hidden wrote:

My point is, in particular, that not only are locks not the panacea for threading, but they have their own problems (deadlock, serialisation, etc). Locks should really be a last resort - as Mr. Fish notes, you can accomplish quite a lot of synchronisation just with a bit of careful design and clever use of memory barriers and ordering.

I'd disagree with both your point above and your characterization of Mr. Fish's article.


Locks certainly are not a panacea, but locking should be the first resort of someone trying to writie correct multithreaded code. Other, much more advanced techniques — such as the memory barrier techniques in his article — should be applied only after the performance of locking has been shown to be inadequate.

Many people try very hard to avoid locking because they've heard that locks are slow, not because they've actually measured their performance or ensured the correctness and efficiency of their software as it is. Most of the time there are other more significant ways to improve the performance of your code before you switch away from locks.

For example, you might have multiple threads writing to a single SQLite database at once. These threads are all going to wind up synchronized by the database because for consistency the database can't actually do more than one write at a time; no amount of switching from NSLock to pthread_mutex to a spin lock to using memory barriers will improve its performance, because ultimately it'll actually be using the filesystem to enforce synchronization. (To complete the example, you'd be best off limiting your code to a single writer thread that follows a work queue model; then you're modeling at a higher level the behavior you'll get at a lower level, but without the overhead of using the filesystem for your locks.)

Multithreading can be hard, but it can also be made much harder by trying to take shortcuts.

  -- Chris

_______________________________________________

Cocoa-dev mailing list (email@hidden)

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: 
 >Preventing beach balls (From: Paul Borokhov <email@hidden>)
 >Re: Preventing beach balls (From: Seth Willits <email@hidden>)
 >Re: Preventing beach balls (From: email@hidden)

  • Prev by Date: Re: NSConnection - is this expected behavior?
  • Next by Date: Re: Need Better Understanding of Modal Delegates
  • Previous by thread: Re: Preventing beach balls
  • Next by thread: Re: Preventing beach balls
  • Index(es):
    • Date
    • Thread