Re: NSConditionLock vs. plain variable question...
Re: NSConditionLock vs. plain variable question...
- Subject: Re: NSConditionLock vs. plain variable question...
- From: "Shawn Erickson" <email@hidden>
- Date: Tue, 9 May 2006 18:16:35 -0700
On 5/9/06, Juan P. Pertierra <email@hidden> wrote:
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.
NSLock/NSConditionLock (also don't forget @synchronized which is my
personal favorite now for many things like this) will have more
overhead then just setting a variable but the overhead exists for a
reason.
Setting and testing a simple variable as you suggest isn't sufficient
to provide for a critical section (it is not guaranteed to be an
atomic operation for one even on a single logical core).
You could consider using atomic test and set functions directly
depending on your exact needs but using a higher-level locking
construct should perform just fine (not knowing exactly the flow of
your application).
-Shawn
_______________________________________________
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