Re: Properties and memory management with overrides.
Re: Properties and memory management with overrides.
- Subject: Re: Properties and memory management with overrides.
- From: Bill Bumgarner <email@hidden>
- Date: Mon, 26 Jan 2009 16:26:32 -0800
On Jan 26, 2009, at 4:00 PM, Quincey Morris wrote:
Although the rationale for non-atomicity runs under the general
thread-safety discussion umbrella, there are actually two separate
issues to consider.
It helps to explicitly *not* think about atomicity under the same
umbrella as thread safety for all the reasons you mention below.
To restate:
Atomicity has very little to do with thread-safety.
All atomicity guarantees is that you'll get and/or set a consistent
value, regardless of who or what is beating upon the method (there are
even ways -- perverse and wrong ways -- of writing nonatomic code that
gives the wrong value in a single thread).
What atomicity does *not* guarantee is that you'll get/set the "right"
value.
Generally, discussion about thread-safety of data like Core Data
properties centers around the possibility of conflicting changes
from multiple threads. Atomicity at the property level doesn't
really help with that (as stated), and the problem must be solved at
a higher level.
Exactly.
However, even if only one thread can be changing the data, atomicity
still matters. If the accessors aren't atomic, multiple read-only
users of the data (in different threads) might get completely bogus
results. This problem *can* be solved by atomicity at the property
level, if you're prepared to take the potential performance hit from
implementing it.
Actually, it really can't be solved at the property level. Individual
properties can generally never carry enough information about
themselves to know what the "right" behavior is in the face of threads.
Example:
@property(...) ... firstName;
@property(...) ... lastName;
@property(...) ... firstAndLastNameForDisplay;
If thread A is changing firstName while thread B is calling
firstAndLastNameForDisplay, atomicity can only guarantee that -
firstAndLastNameForDisplay won't crash.
What it can't do is guarantee that you'll get the correct value from -
firstAndLastNameForDisplay. For that to work, your model object has
to know all about the dependencies between the three properties.
Looks simple, but it isn't.
Example question: Does changing firstName mean that
firstAndLastNameForDisplay returns nothing until lastName has also
been changed? ... what about the same lastName? I could go on.
b.bum
_______________________________________________
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