On Oct 28, 2010, at 7:01 AM, Jonny Taylor wrote: > I currently have a property declared as follows: > @property(atomic, readwrite, retain) MyFrame* latestFrame; > > When the value is set, I would like to broadcast a notification on the main > thread, and one way of doing that would be to write my own custom setter that > sets the value and then broadcasts the notification. What I am not sure about > is how much I need to do to ensure this is threadsafe. I have only been able > to find limited, rather contradictory information on this. > > When I write my own setter function, does the "atomic" qualifier have any > meaning? What I am trying to work out is whether the runtime will bracket my > function with appropriate locking code, or whether I need to do that myself - > and so crucially, do I ALSO need to write a custom getter function that is > subject to the same manual locking? > > [I have since wondered whether actually the "right" way of achieving what I > want is to implement a didChangeValueForKey method from which I do the > broadcasting. Any comments on that approach would also be welcome!]
In the manual case, 'atomic' only has meaning if you make it meaningful. I'd be interested in knowing why you need an atomic property in this case as atomicity at the property level rarely contributes to thread safety. If you do go this route, you need to write both the getter and setter with relative atomicity between the two. You can't write just one as there is no way for your custom getter or setter to interact with the atomicity mechanism of the other. There is no way for the runtime to bracket your code with an atomicity ensuring mechanism as there is no complete way to figure out what locking you might be doing in your code. Note that sending notifications to other threads while holding locks in the current thread (or queue) is rife with danger & fragility. It is great way to create deadlocks and, if not, to end up with a solution that has all the maintenance costs of multi-threaded code combined with all the performance wins of single threaded execution.... b.bum _______________________________________________ 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]
