Re: @synchronized in thread safe accessors
Re: @synchronized in thread safe accessors
- Subject: Re: @synchronized in thread safe accessors
- From: Michael Ash <email@hidden>
- Date: Fri, 6 Feb 2009 21:23:56 -0500
On Fri, Feb 6, 2009 at 7:19 PM, Nick Zitzmann <email@hidden> wrote:
>
> On Feb 6, 2009, at 5:09 PM, Kyle Sluder wrote:
>
>> Then why bother with @synchronized? Don't fix what isn't broke.
>
> It's one less ivar to worry about. I retro-fitted the lock to one other
> object I wanted to make thread-safe, only because I couldn't think of a way
> of doing this safely with @synchronized(), and thought I'd ask before
> committing. And now I'm wondering how @synthesize does atomic sets
> internally...
I'm pretty sure it just does @synchronized(self) or the equivalent.
>> Since you're using a setter, you need to take out the lock on a
>> different object. You might be able to take it out on self (a la Java
>> synchronization), or you might have to create a separate dummy
>> NSObject on which to take out the lock. And we've now come
>> full-circle to the ivarLock you had in your original implementation.
>
> Yeah, that's what I thought. But thanks for confirming this. Guess
> NS(Recursive)Lock still has its uses...
Certainly. @synchronized is a convenience, nothing more. It's
basically just a wrapper around a recursive lock that gets looked up
by object ID. Theoretically, each object gets a lock. Practically
speaking, there's a pool of locks that get portioned out, hash-table
style.
But the important thing is that, aside from this magical mapping of
objects to locks, @synchronized does nothing that other locking
techniques can't also do.
One last thing: creating thread-safe getters and setters is almost
never the right thing to do. It's never sufficient and rarely required
to achieve overall thread safety. There are cases where it's useful
but they're rare. It's much better, in most cases, to concentrate on
synchronizing larger pieces of your object graph instead.
Mike
_______________________________________________
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