> -----Original Message----- > From: Chris Hanson [mailto:[EMAIL PROTECTED] > Sent: Tuesday, November 04, 2008 10:49 AM > To: Karan, Cem (Civ, ARL/CISD) > Cc: [email protected] > Subject: Re: properties, threads, and KVO > > On Nov 4, 2008, at 7:20 AM, Karan, Cem (Civ, ARL/CISD) wrote: > > > KVO is ideal, but I don't know it works across threads. > > KVO doesn't do anything special with respect to threads. > > Since it's synchronous, that means KVO notifications are > delivered in the thread in which they occur, just as if you > had set up the server to call methods on your client directly. > > > I know that properties are supposed to default to > thread-safe, and I > > know that as long as I don’t explicitly specify > getter/setter methods, > > properties should be KVC/KVO compliant, but I'm not sure if > the above > > is 100% kosher. Is there anything I should be worried about? > > This term "thread-safe," I do not believe it means what you > think it means. ;) > > Properties are by default *atomic*. That means no matter > what multiple threads are doing with an individual property, > threads will either see the "before" or "after" state of the > property itself, never an intermediate state. > > What it *doesn't* mean is that you'll always see a consistent state of > *multiple* properties. That's something you'll have to > enforce yourself, either at the per-object or > per-object-graph level. The canonical example is a Person > object with atomic givenName and familyName properties and a > fullName property that returns the two as a single string: > > @interface Person : NSObject > @property (copy) NSString *givenName; > @property (copy) NSString *familyName; > @property (readonly) NSString *fullName; @end > > Atomic properties only guarantee that you won't get back a > zombie from any of the above properties. They make no > guarantee that fullName won't be "Cem Hanson" or "Chris Karan."
Actually, this is EXACTLY what I was expecting. In my case, I only have one object (the image) that I care about cutting across multiple threads, so I don't have the worry about the problems you describe above. I *DO* have to worry about my properties being 'retain' instead of 'copy' though; thanks for the code snippet above, I'd forgotten about that. > Furthermore, if anything is observing a Person using KVO, it > will receive change notifications for the Person's properties > on the thread on which the change takes place. It needs to > know whether the Person it is observing can change in an > arbitrary thread and be prepared for that if it can. > > The code you posted doesn't really take this into account; it > appears > to expect the KVO notification to be delivered "across" threads. > Furthermore, it doesn't do any locking or other > synchronization, which will still be required if both the > client and server are dealing with the same object. It's not > something the compiler can be "smart" about > -- you need to handle that yourself. And that was what I was really wondering about; you see, my reading of how properties in Objective-C 2.0 works is that they are always atomic. Thus, if I got a KVO notification that something changed, I could make a grab for it across threads safely. That still didn't fix getting stuff working on the main thread, which (I just realized) is why I should be using performSelectorOnMainThread:withObject:waitUntilDone:... and I just tested it out, it works. Thanks, Cem Karan _______________________________________________ Cocoa-dev mailing list ([email protected]) 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]
