Re: Seeking advice on NSLock usage
Re: Seeking advice on NSLock usage
- Subject: Re: Seeking advice on NSLock usage
- From: Evan Schoenberg <email@hidden>
- Date: Sun, 12 Dec 2004 22:05:55 -0600
(Clark, I loved your talking stick analogy :) )
One thing to note is that if you use a simple [NSLock lock] check to
wait (in your main thread) until the secondary thread is finished, you
won't see any advantages from threading, since your main thread will
lock until it "obtains the lock" -- that is, until the secondary thread
is done.
Depending on your implementation, one thing you might look at doing is
using (pseudocode):
if([myLock tryLock]){
//Obtained the lock; do whatever we want to do
//Now unlock it when we are done
[myLock unlock]
}else{
//We could not obtain the lock; we will get here immediately.
//Use an NSTimer or NSInvocation to try again after a set period,
giving feedback to the user that we are
//waiting for the search to complete.
//For example, call tryAgain in 5 seconds
[self performSelector:@selector(tryAgain) withObject:nil
afterDelay:5.0];
}
Hope that helps,
Evan
www.adiumx.com
On Dec 12, 2004, at 9:34 PM, Clark Cox wrote:
On Sun, 12 Dec 2004 15:36:17 +0000, Jeremy Dronfield
<email@hidden> wrote:
I have an application which carries out file system searches according
to criteria set by the user. Searching is done in a separate thread,
so
as not to lock up the program. Whilst a search is going on, the user
is
thus able to tinker with the controls which set search criteria.
Disabling the interface seems a clumsy solution, so this seems like a
case for using locks. I've read what I can find about them, but I have
two outstanding questions.
1. How do locks work? When a lock is activated inside a setter method,
does it, in effect, disable the setter method by blocking changes to
the variable? - or does it create a locked copy of the variable at the
time when the program goes multithreaded, leaving the rest of the
program free to alter it?
The lock itself has nothing to do with what it is locking. You can
think of it as a "talking stick" (to borrow a term from kindergarten).
Whomever has the stick is allowed to talk, and everyone else has to
wait their turn.
Calling [aLock lock] is essentially saying "I want to do my thing now,
is the talking stick available? If so, give it to me, if not, then
I'll wait until I can get it."
On the other hand, calling [aLock unlock] is essentially saying "OK,
I'm done, is anyone else waiting on the talking stick? If so, then
here it is, you can have it."
2. It appears that NSLock can't be used with non-object variables.
Some
of my search criteria are strings, but most are BOOLs and ints. How
can
I lock those? Will I have to change them to NSNumbers, or is there
some
other approach?
An NSLock isn't associated with any particular variable, it is simply
a way to get different threads to "play nice", and wait their turns.
--
Clark S. Cox III
email@hidden
http://www.livejournal.com/users/clarkcox3/
http://homepage.mac.com/clarkcox3/
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden