Re: multithreading, dual-core

Subject: Re: multithreading, dual-core

From: Chris Hanson <email@hidden>

Date: Mon, 26 Feb 2007 13:48:05 -0800

Delivered-to: email@hidden

On Feb 26, 2007, at 10:30 AM, George Warner wrote:

On Sun, 25 Feb 2007 11:37:21 -0800, Shawn Erickson <email@hidden>
wrote:
Often it is the algorithm and not the locking overhead that is a problem.

One "newbie" mistake I often see is over locking. The fastest and least
likely lock to deadlock is the ones you can completely avoid. Google
"lockless programming".

If at all possible use atomic operators (great for ref-count modifiers);
then spin-locks and only as a last resort conditional mutexes.

I'd say exactly the opposite: One newbie mistake that I often see is not locking sufficiently, and trying to optimize away synchronization before ensuring correctness.

Make your code correct using whatever locking mechanisms your framework provides; e.g. in Cocoa, for example, use NSLock, NSRecursiveLock, and @synchronized as appropriate. Then, after measuring your performance, if your measurements indicate that synchronization is resulting in significant delays, and it's not for architectural reasons (such as a bunch of threads all hitting a single shared resource) then consider dropping down a layer to see if you can optimize your synchronization itself.

Usually your best optimization opportunities in this space are architectural and algorithmic.

-- Chris

_______________________________________________ Do not post admin requests to the list. They will be ignored. Xcode-users mailing list (email@hidden) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/xcode-users/email@hidden This email sent to email@hidden

Follow-Ups:

Re: multithreading, dual-core
- From: George Warner <email@hidden>

References:

>Re: multithreading, dual-core (From: George Warner <email@hidden>)