Re: Thread safety of Cocoa Bindings
Re: Thread safety of Cocoa Bindings
- Subject: Re: Thread safety of Cocoa Bindings
- From: Bill Bumgarner <email@hidden>
- Date: Tue, 6 Dec 2005 14:54:51 -0800
On Dec 6, 2005, at 1:47 PM, John Stiles wrote:
It's difficult to "test" for thread-safety. Many threading problems
are very rare in practice, or only occur with a certain sequence of
calls which your code may not be making. If something isn't
documented as thread-safe, I would absolutely avoid it in threaded
code.
John is quite correct.
To repeat:
• If the documentation does not say something is thread safe, it is
not thread safe. Period. End of story.
• It doesn't matter how many locks you put around "not thread safe"
code. It will still not be thread safe(1).
• No amount of unit or automated testing can guarantee thread
safety. It is like math; one million examples of a particular
algorithm's behavior does not a proof make.
• Assumptions will kill you (or, at least, reduce your life
expectancy). Threading related bugs are often incredibly difficult
to reproduce, much less fix. See previous point; if you can't
prove the thread safety of a design or body of code, you shouldn't be
using threads.
• Many bodies of threaded code perform worse than a well considered
single threaded implementation because the "debugging process" has
added so many locks that the threads spend most of their time blocked
on each other.
--
1- Really. The only way thread "unsafe" code can be made thread safe
is by absolutely positively no-exceptions-allowed guaranteeing that
the code is only ever run in a single thread.
Don't get me wrong -- threads are incredibly powerful and useful.
Concurrent, non-protected memory, coding is also one of the most
difficult things to get right. To further complicate matters,
threaded code on the Mac OS X platform may be running on wildly
different architectures, ranging from low-end, single core, machines
to screamingly fast quad-core machines that are actually a
combination of 2 CPUs and 2 Cores (each of which has different
threading semantics).
b.bum
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden