• 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: Accessing array in thread safe way
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Accessing array in thread safe way


  • Subject: Re: Accessing array in thread safe way
  • From: Don Quixote de la Mancha <email@hidden>
  • Date: Wed, 07 Mar 2012 14:55:51 -0800

> Personally, I avoid sharing mutable data between threads if I possibly can. It can quickly turn into an unholy mess.
>
> —Jens

The key to not just safe but performant multithreaded code is to redesign your data structures and algorithm so that you need not synchronize at all.

Many problems do ultimately require some locking but close examination often yields the insight that it doesn't need to be locked in as many different places, to be locked for as long when it is locked at all, or locked as frequently.

If you start with a straightforward single threaded solution to some common problem, break it down into multiple threads so as to share the load among multiple cores then add locks where you think they are necessary you are unlikely to ever get all the threading bugs out.

But there are often ways to divide up the problem so that many of the locks you thought you needed turn out to be unnecessary.

Just acquiring a lock takes time and will require costly context switches into and back out of the kernel even if the acquisition succeeds. if another thread attempts to acquire that same lock it will totally block until the lock is released by it's original owner and that second thread's acquisition succeeds.  During the time it is blocked that thread is not serving your user's needs.

If you have to wait to acquire locks too much you may find that naively designed threaded code is slower than well designed single threaded code, even on multiple cores.

If you possibly can replace locking algorithms with what are commonly but incorrectly called lock free algorithms.  They use Atomic Arithmetic Primitives provided by the CPU Instruction Set  Archetector to manage very short term locks on single words of memory.

If a thread performs Atomic Arithmetic on a memory word, it will still lock it but is guaranteed to release that lock on the very next instruction.  A second thread that attempts to operate Atomically on the same word will stop cold but only for a few clock cycles.  At least that's better than suspending the entire thread, which costs expensive kernel  calls and returns.

Often overlooked is the performance penalty of maintaining multicore cache coherency.  If you've got your locking right you won't have any discernible bugs but if two or more cores read or write the same cache line simultaneously your perfermance will be poor due to all the cache flushing so that all the cores maintain an identical view of memory.

To improve performance share as little data as possible, access it as infrequently as possible and if you access it at all, finish what you're doing with the shared data as quickie as you can.

The best is to find some way to order access to shared regions so that multiple cores tend not to access the same cache line at the same time.

This is all very vague and conceptual so it may not be clear how you need to revise your source so as to heed my advice.

But we have always known that hardware can go faster if we use more instances of it, and it is a lot easier to design a computer with two cores than it is to design a single core that yields useful results twice as fast.

The literature has rich discussions of concurrent processing going all the way back to the 1940s.  The problems you and I face today may well have been solved and published decades ago. Even if the algorithms were patented those patents may well have expired by now.

I'm sorry but I cannot recommend any reading.  I expect others on this list can.

Don Quixote de la Mancha
Software of Elegance and Beauty
http://www.dulcineatech.com/
email@hidden


_______________________________________________

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


  • Follow-Ups:
    • Re: Accessing array in thread safe way
      • From: Per Bull Holmen <email@hidden>
References: 
 >Accessing array in thread safe way (From: "Jan E. Schotsman" <email@hidden>)
 >Re: Accessing array in thread safe way (From: Jens Alfke <email@hidden>)

  • Prev by Date: Re: No indentation when displaying an icon in an NSMenuItem
  • Next by Date: Twitter Account accountStore Permissions Dialog / Alert ...
  • Previous by thread: Re: Accessing array in thread safe way
  • Next by thread: Re: Accessing array in thread safe way
  • Index(es):
    • Date
    • Thread