Re: Do I need private accessor methods?
Re: Do I need private accessor methods?
- Subject: Re: Do I need private accessor methods?
- From: Chris Hanson <email@hidden>
- Date: Fri, 28 Apr 2006 19:30:50 -0700
On Apr 28, 2006, at 3:15 PM, Ryan Britton wrote:
They are very useful for ensuring your code is threadsafe. For
this reason alone I recommend using them. Take a look at the
following link to solve your last concern:
As Shawn pointed out, there's a lot more to thread safety than
synchronized accessors. In particular, synchronized accessors can
have a significant cost in performance and lull you into a false
sense of security. Take the following example. Assume you have the
following "thread-safe" (internally locking) accessors:
- (int)foo;
- (void)setFoo:(int)value;
Now you write this simple piece of code that uses them:
[someObject setFoo:[self foo] + 1];
Is this thread-safe? Not at all! Another thread could send -setFoo:
to someObject in between when your code sends -foo and setFoo:.
(After all, we're assuming that these accessors are intended
explicitly for use from multiple threads — if they weren't, they
wouldn't implement any locking.)
What you actually need to do is delineate a transaction scope or
critical section around shared information that needs to remain
consistent but be manipulated from multiple threads. The shared
information in the above case isn't really the _foo instance variable
that -foo and -setFoo: are covers for. It's the state of someObject
that's shred, and that needs to be kept consistent.
That's what the various kinds of locks are for — NSLock,
NSRecursiveLock, NSConditionLock — as well as the @synchronized
keyword. You can expose these directly from your objects, or you can
make your objects conform to the NSLocking protocol and implement its
methods to invoke the appropriate methods on an internal lock to give
it transaction scope information.
Accessors for private state can be useful if you're doing so to make
your class easy to subclass or refactor. Multithreading support is
entirely orthogonal.
-- Chris
_______________________________________________
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