I was speaking for a programmer's own code. When you're using someone
else's classes that modify their own data or internal state, then it's
not just reading memory and therefore neither is the program. But if
you truly are just reading then synchronization is not necessary.
The point I was driving at is that shared data could, as in the
example I made, be shared without worrying about synchronization
problems; shared data does not always need locks simply because it's
shared. When to lock and when not to lock is always one of the first
things a beginner should learn because of the performance penalties
locking incurs.
On May 8, 2008, at 12:45 AM, Chris Hanson wrote:
What I'm saying is that in the general case you cannot assume that
just because you're reading you're "safe."
This gets people into a lot of trouble with Core Data, for example,
because simply accessing a property of an object will cause the
framework to do things that require state. You cannot thus simply
share Core Data managed objects between multiple threads without
being extremely careful to lock the object graph.
Similarly, if you are given an arbitrary object, unless it makes
explicit guarantees about the safety of doing so — whether as part
of the language standard, such as the example you give above, or via
documentation — you cannot assume that it is safe to access from
multiple threads at once.
For example, consider an immutable object that has a property which
is expensive to calculate. It could easily cache this value behind
the scenes. It's still immutable from its users' perspective, but
it's likely to behave incorrectly in some way if used from multiple
threads at once. And unless the object's class documentation says
instances are safe to share across multiple threads, you'd be
violating its API contract by doing so.
There is nothing that causes more bugs in writing threaded code than
assumptions about what is and isn't safe at any given instant. You
can't assume, you must know.
_______________________________________________
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 [EMAIL PROTECTED]
