On Jan 26, 2009, at 16:26, Bill Bumgarner wrote:
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:
Indeed. In general, accessing a property can have 3 possible outcomes:
1. The right value.
2. A wrong value.
3. Complete and utter garbage.
Atomicity can eliminate the last case only. In general, that doesn't
solve any problems at all, but in practice it might.
Any notification-driven system (even single-threaded) can present an
observer with a temporarily inconsistent data model (as in your
firstName/lastName example). Therefore, observers should typically be
coded defensively with regard to outcome #2 anyway. Coding defensively
against outcome #3 is unlikely to practicable. *That's* the problem I
meant can be solved by atomicity.
_______________________________________________
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
