Re: Re: Synchronizing Thread Execution
Re: Re: Synchronizing Thread Execution
- Subject: Re: Re: Synchronizing Thread Execution
- From: "Shawn Erickson" <email@hidden>
- Date: Wed, 6 Dec 2006 10:48:34 -0800
On 12/6/06, Scott Ribe <email@hidden> wrote:
So unless @synchronized
does some compiler voodoo with a hidden static variable to only evaluate it
once, or uses something other than object identity in order to map locks,
the example is wrong.
...spring boarding off of Scott's post...
This thread has seen many twists and turns so I want to help clarify
how to use @synchronized (at least I hope to do that).
The value you supply to @synchronized is used to define the "logical
context" that the synchronized block (critical section) is
synchronized against. All critical sections, for all threads involved,
that shouldn't allow concurrent execution must have the same value
provided to their respective @synchronized blocks. If they see
different values then they are synchronizing against different
unrelated logical contexts and hence not synchronizing against each
other.
You are free to create any objects you want to define synchronization
contexts as needed. It is up to you to decide. Sometimes synchronizing
against "self" makes sense sometime it doesn't... it fully depends on
the critical sections (and the data they manipulate) that you need to
synchronize. You just need to make sure that all threads involved have
access to the exact same value so they are all synchronizing against
the same logical context.
I believe the semantics of @synchronized implies that the value you
supply to synchronize is an object in the objective-c sense (aka a
pointer to an object) and synchronized is always a recursive locking
construct. Ideally in your code you should make attempts to pass only
objects. ...however it would be nice to see a clearer statement of the
expected semantics of @synchronized from Apple.
The current implementation of synchronized doesn't really care if what
you pass is an object. It only uses the value as a key to lookup a
mutex that is used to protect the critical section. This of course is
an implementation detail and unless stated otherwise in Apple
documentation you shouldn't assume it will always be this way. With
that said... Apple likely can't change it from this current
methodology without possibly breaking existing applications however
note 64b binaries can break binary compatibility so Apple has more
freedom to make changes to something like this.
In theory Apple in the future could associate a mutex with all objects
created by the objective-c runtime and then change synchronize to
fetch this mutex... this could result in synchronize only being able
to work with objects (pointers to objects). Note this is only
speculation about a possible change and not intended as any statement
about what Apple is or isn't changing in regards to @synchronized
(simple fact is I haven't even looked at this in my Leopard seed yet).
-Shawn
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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