RE: properties, threads, and KVO
RE: properties, threads, and KVO
- Subject: RE: properties, threads, and KVO
- From: "Karan, Cem (Civ, ARL/CISD)" <email@hidden>
- Date: Tue, 4 Nov 2008 11:32:38 -0500
- Thread-topic: properties, threads, and KVO
> -----Original Message-----
> From: Chris Hanson [mailto:email@hidden]
> Sent: Tuesday, November 04, 2008 10:49 AM
> To: Karan, Cem (Civ, ARL/CISD)
> Cc: email@hidden
> 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@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