Re: Custom setter for atomic property
Re: Custom setter for atomic property
- Subject: Re: Custom setter for atomic property
- From: Jonny Taylor <email@hidden>
- Date: Thu, 28 Oct 2010 17:16:52 +0100
Thanks for your answers Bill, that has cleared up some of my confusion.
> 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.
I have subsequently discovered this myself! The problem I encountered (which probably should have been obvious) was that I was reading the property, but then by the time I was actually doing something with it it had been released by another thread.
> 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.
I have ended up writing a function setCurrentFrame, and a function getAutoreleasedCurrentFrame which ends with [[currentFrame retain] autorelease]. Both are bracketed with the same mutex. Does that sound like a sensible approach, or am I still going about this the wrong way?
Incidentally, I suspect that approach would be KVO compliant if I was to rename getAutoreleasedCurrentFrame to just currentFrame, but I'm inclined to leave it as-is for the moment to remind myself I am doing something a bit strange.
> 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.
OK
> 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....
My situation is that I am receiving camera frames on a background thread, and need a way of informing various windows that their displays should be updated to reflect the fact that a new frame has been received. This GUI work needs to be done on the main thread (I believe...). In addition, I take advantage of the coalescing features of notifications to avoid unnecessary updates. Thus I am keeping the currentFrame variable up to date in a threadsafe manner, and then after updating it (and releasing the lock) I post a notification to the main queue, with coalescing. Does that sound like a reasonable approach?
I definitely need to access currentFrame in a threadsafe manner, but hopefully my description shows that the multithreaded relationship for the notifications and variable updates is not there for performance reasons, if that makes sense. I am more than aware of the trouble multithreading brings, but the nature of the code makes it pretty unavoidable.
Jonny_______________________________________________
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