Re: Synchronizing Thread Execution
Re: Synchronizing Thread Execution
- Subject: Re: Synchronizing Thread Execution
- From: Antonio Nunes <email@hidden>
- Date: Thu, 7 Dec 2006 10:24:41 +0000
On 6 Dec 2006, at 22:53, Scott Ribe wrote:
my one
printed Objective-C reference is too old to mention @synchronized
The reason I'm still flogging this is that I'm planning to file my
own bug
report asking for better documentation on this, so first I'd like
to know if
there is some Objective-C reference that I've missed which
specifies the
behavior more thoroughly.
From the current Objective-C Programming Language reference:
Synchronizing Thread Execution
Objective-C supports multithreading in applications. This means that
two threads can try to modify
the same object at the same time, a situation that can cause serious
problems in a program. To protect
sections of code from being executed by more than one thread at a
time, Objective-C provides the
@synchronized() directive.
The @synchronized()directive locks a section of code for use by a
single thread. Other threads are
blocked until the thread exits the protected code; that is, when
execution continues past the last
statement in the @synchronized() block.
The @synchronized() directive takes as its only argument any
Objective-C object, including self.
This object is known as a mutual exclusion semaphore or mutex. It
allows a thread to lock a section of
code to prevent its use by other threads. You should use separate
semaphores to protect different
critical sections of a program. It’s safest to create all the mutual
exclusion objects before the application
becomes multithreaded to avoid race conditions.
Listing 3-3 shows an example of code that uses self as the mutex to
synchronize access to the instance
methods of the current object. You can take a similar approach to
synchronize the class methods of
the associated class, using the Class object instead of self. In the
latter case, of course, only one thread
at a time is allowed to execute a class method because there is only
one class object that is shared by
all callers.
Listing 3-3 Locking a method using self
- (void)criticalMethod
{
@synchronized(self) {
// Critical code.
...
}
}
Listing 3-4 uses the current selector, _cmd, as the mutex. This kind
of synchronization is beneficial
only when the method being synchronized has a unique name. This is
because no other object or class
would be allowed to execute a different method with the same name
until the current method ends.
Listing 3-4 Locking a method using _cmd
- (void)criticalMethod
{
@synchronized(NSStringFromSelector(_cmd)) {
// Critical code.
...
}
}
Listing 3-5 shows a general approach. Before executing a critical
process, the code obtains a semaphore
from the Account class and uses it to lock the critical section. The
Account class could create the
semaphore in its initialize method.
Listing 3-5 Locking a method using a custom semaphore
Account *account = [Account accountFromString:[accountField
stringValue]];
// Get the semaphore.
id accountSemaphore = [Account semaphore];
@synchronized(accountSemaphore) {
// Critical code.
...
}
The Objective-C synchronization feature supports recursive and
reentrant code. A thread can use a
single semaphore several times in a recursive manner; other threads
are blocked from using it until
the thread releases all the locks obtained with it; that is, every
@synchronized() block is exited
normally or through an exception.
When code in an @synchronized() block throws an exception, the
Objective-C runtime catches the
exception, releases the semaphore (so that the protected code can be
executed by other threads), and
re-throws the exception to the next exception handler.
-António
-----------------------------------------
Accepting others as they are
brings a wonderful freedom
to your own mind.
--The Peace Formula
-----------------------------------------
_______________________________________________
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