Re: Memory Management
Re: Memory Management
- Subject: Re: Memory Management
- From: Wade Tregaskis <email@hidden>
- Date: Wed, 30 Jul 2003 17:08:33 +1000
- (void)setName:(NSString *)newNamemet {
[newName retain];
[_name release];
_name = newName;
}
Yes it will, in this case. The problem with the previous example
(above) is that you release [and possibly dealloc] your existing
instance, then could have some other code which refers to _name
before you change it to newName. _name at this point is a dangling
pointer. If instead you autoreleased your existing instance, any
chance reference to _name before you change it would still return a
valid, existing object.
I'm glad you explained that, because I was totally at a loss as to why
the above code was not "thread-safe" while the autorelease version is.
I don't agree that the autorelease version is thread-safe, but at
least now I understand your logic.
In the situation you describe, where another thread swoops in and
grabs the value of _name in the midst of the value being changed, I
would say there is a potential race condition at a higher level even
if the autorelease insures that the object, at lest, was not
dealloced. The parent code calling this accessor is almost certainly
incorrect if this is possible, and I would actually prefer the version
that caused the swooping thread to get a dealloced object, as I might
get a crash that would clue me into the problem. Looks like the
autorelease version would tend to paper over the problem and make any
potential race conditions devilishly harder to find.
If the value was very recently valid, chances are it's not a big
disaster if you get it by accident. After all, it's just a matter of
where you draw the line - I could say you should only get the new value
*after* the setter completes, not before/during as we're all taking as
given.
But I agree with you otherwise, that this isn't a perfect solution.
But neither is using locks, or using retain+autorelease in your getter
methods, due the potentially gigantic overhead both these methods add.
I generally find it's a better idea to put locks around large swathes
of code, on a task level, rather than on individual objects. Then,
even though there may be lots of non-perfect code being used, it's
irrelevant. And the performance impact is immeasurable.
The chance of having the autoreleased [old] instance deallocated before
the caller gets a chance to use/retain it is pretty slim, I would say.
Unless you're explicitly releasing the pool immediately after the call
or somesuch. But then again, if you're explicitly releasing a pool you
should be retaining anything you really want first...
Wade Tregaskis
-- Sed quis custodiet ipsos custodes?
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.