On Mar 8, 2012, at 11:57 PM, Quincey Morris wrote: > On Mar 8, 2012, at 14:29 , Charles Srstka wrote: > >> For those two examples, it seems like having the default accessor return an >> immutable array via copy would solve the issue. > > It wouldn't solve, e.g., the possibly inconsistency between 'array.count' and > a subsequent reference, unless it was coded to keep a "consistent" local > reference to the copy of the array, in which case you'd want the copy to be > explicit in the API so that a reader of the code would be aware, and that > would be a non-atomic-level approach anyway. > > I also wanted to point out that there's another defect in Tamas's code: it > needs an explicit atomic 'copy' implementation, and therefore an explicit > atomic 'mutableCopy' implementation. And who knows what else … > > I'm begging ya to forgeddaboudit. The atomicity solution is a fantasy**. You > can't solve thread safety at that level. > > > > ** However, we don't know the scenario Tamas wrote the code for. It's > possible atomicity solved whatever issue he was facing, that wasn't general > thread safety. It's also possible he didn't solve anything, but just changed > a likely-to-cause-a-crash bug into a > impossible-to-crash-but-likely-to-cause-a-rare-and-subtle-but-almost-impossible-to-debug-error > bug. >
Thanks Quiencey to pointing this out, however, what you suggest instead of the current implementation? What I use for this class is putting and/or update objects into it from different threads, then access it from an other (reader) thread (via objectAtIndex: and by enumarating). _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
