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 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]
