Re: Thread Safety - A Theoretical Question
Re: Thread Safety - A Theoretical Question
- Subject: Re: Thread Safety - A Theoretical Question
- From: Greg Parker <email@hidden>
- Date: Mon, 12 Oct 2009 14:42:16 -0700
On Oct 12, 2009, at 1:47 PM, André Berg wrote:
I am designing my first real class and I am wondering about thread
safety. I have read the Cocoa Fundamentals and also the Threading
Programming Guide but there was one question forming in my head
which I couldn't quite find an answer for. I guess it is something
that class designers deal differently with.
My class internally doesn't use any threads at all (well apart from
an NSTask ivar and readInBackgroundAndNotify). The only scenario I
can think of that would be dangerous is if in the calling code (the
code from the user of my class) there are two threads which could
simultaneously access the same instance of my class.
In that case is it my responsibility to guard all access to my
class' thread unsafe ivars (like mutable objects for example) or is
it the responsibility of the user of my class to guard all access to
my class' instances in his code?
With regards to this, should I care about thread safety at all? If
you are designing a class, even without any concurrency in it at
all, where do you decide to worry about thread safety in code
outside your reach?
There are many different patterns of thread-safety and -unsafety, with
varying performance, implementation difficulty, and restrictions on
clients. If you're writing code that you expect other people and other
code to use, you should always think about thread safety. Of course
that thought may only go as far as deciding and documenting that the
code is thread-unsafe and client beware. But it really is the thought
that counts here.
Some examples, in rough order of increasing multithreaded-ness from
the client's perspective. You'll probably want to pick one of these
patterns, document the choice, and design and implement around that
choice.
* Thread-unsafe / main thread only. Many AppKit classes work this way.
The implementer did nothing to make threads work. The client may only
use it from the main thread.
* One thread per instance. Much of Core Data works this way. A
particular instance may only be used from a single thread, but other
threads may simultaneously use other instances. The implementer made
sure that any global variables or shared data was thread-safe inside
the implementation, but per-instance data was not made thread-safe.
* One lock per instance. Mutable containers often work this way. A
particular instance may be used on multiple threads, but only if all
uses of that instance are protected by a single mutex. Other instances
may be protected by other mutexes.
* Multiple readers, single writer. Mutable containers often work this
way. A particular instance may be used without mutation on multiple
threads simultaneously without synchronization, but any mutation must
be mutually exclusive with other mutations and all non-mutators. (I.e.
you can have multiple threads calling -objectAtIndex: on an
NSMutableArray, but -objectAtIndex: and -setObject:atIndex: on
different threads need to be protected from each other.)
* Immutable. NSValue and immutable containers work this way. A
particular instance can be used on multiple threads simultaneously,
and since it can't be modified there's no need to add synchronization
to protect mutations. This is a special case of multiple reader /
single writer with zero writers.
* Anything goes. Any method may be called from any thread at any time,
and the implementation will make it work. Usually this is hard to
implement, hurts performance, and greatly restricts the API design.
--
Greg Parker email@hidden Runtime Wrangler
_______________________________________________
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