Re: Threading - How its done?

FROM : Michael Vannorsdel
DATE : Thu May 08 09:16:48 2008

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.