Re: NSConditionLock vs. plain variable question...
Re: NSConditionLock vs. plain variable question...
- Subject: Re: NSConditionLock vs. plain variable question...
- From: Lon Giese <email@hidden>
- Date: Tue, 9 May 2006 23:48:36 -0700
yes locking threads takes a lot of over head.. but if you gotta do it
you gotta do it. generally you only have to lock threads when more
than one thread is CHANGING a particular variable.... if only one
thread is changing the variable and the other is just looking at it
then probably no need to do any locking... which is what it sounds
like you are describing... --- say you have a variable == 10 , two
threads read the vairable at the same time increment it and store it..
now the variable is == 11 and not 12 as you would probably have
wanted... in this case you have to lock the thread when entering the
method that increments the variable...
On May 9, 2006, at 6:01 PM, Juan P. Pertierra wrote:
Hello,
My Cocoa application has a background thread which contains an async
callback function which gets periodically called by the system.
At one point, my main thread wants to change the value of a single
variable which is used in the callback, so I want to make sure a
callback is not in progress before changing it.
I'd like to keep the callback as simple as possible. Is there any
reason not to use just a simple global variable "inCallback", set it
to "1" at the beginning at the callback and set it to "0" at the end
of the callback, then just check it in the main thread? i.e. if
"inCallback == 1" then wait to change the variable, until "inCallback
== 0". It seems like NSConditionLock/NSLock will have more overhead
than just changing the value of a variable, but I'm probably wrong.
Thanks,
Juan
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
email@hidden
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