Re: Thread Safety - A Theoretical Question
Re: Thread Safety - A Theoretical Question
- Subject: Re: Thread Safety - A Theoretical Question
- From: Peter Duniho <email@hidden>
- Date: Mon, 12 Oct 2009 14:41:10 -0700
On Oct 12, 2009, at 1:47 PM, André Berg wrote:
[...] 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?
IMHO, it is perfectly legitimate for you to not do any work toward
making your class thread-safe. In fact, you'll see that philosophy
all throughout Cocoa, as well as any number of other mainstream
programming libraries and frameworks.
If you have a class that is specifically intended to be used in a
multi-thread environment, or which while perhaps not specifically
about threading, still is most useful when used in a multi-thread
environment, then IMHO thread-safety is an important consideration.
But if you have a class that is equally useful when used in a single
thread as it is if used in a multi-thread scenario, and especially if
you expect client code to more often be single-threaded, then it is
IMHO better for you to leave the thread-safety to the client of your
class (which might still be your own code, for that matter...just
somewhere outside your class).
Oh, and by the way, IMHO it also doesn't much matter whether your
class uses threads internally or not. You may well find it
advantageous to use threads internally, but if this isn't exposed to
the client of your class at all, I don't see how that would suggests
that the external API of your class should have to be thread-safe.
In the end, to me it comes down to how often someone's going to have
to implement thread-safety to use your class. If that's going to come
up a lot, then you might as well go to the trouble to implement thread-
safety in your class (and make sure you do it right). If it's not
going to come up a lot, keep your class simpler and leave out the
thread safety. Thread-safety has an implementation cost and a run-
time cost, and so should be borne only where it's cost-effective to do
so.
Pete_______________________________________________
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