Re: NSConditionLock vs. plain variable question...
Re: NSConditionLock vs. plain variable question...
- Subject: Re: NSConditionLock vs. plain variable question...
- From: Shaun Wexler <email@hidden>
- Date: Wed, 10 May 2006 10:55:56 -0700
On May 9, 2006, at 6:01 PM, Juan P. Pertierra wrote:
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.
You need to use an ATOMIC function to change a flag or counter value,
which provides for multi-processor synchronization; dimply declaring
a variable as volatile will not ensure correct operations. You could
wrap the callback function with a flag or entry counter, or
preferably just flag/mutex the dependent variable (ie cache a local
copy on the stack upon entry to your callback, optionally loading it
via an atomic accessor).
--
Shaun Wexler
MacFOH
http://www.macfoh.com
_______________________________________________
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