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: Wed, 10 May 2006 00:17:11 -0700
I forgot to say in the case below where
more than one thread is CHANGING a particular variable
all you need is a simple NSLock. NSConditionLock is for more
complicated stuff like when you want a thread to stop executing until
some condition is met: like wait for an items in a task list... one
thread fills the list and set the condition == TASKS_AVAILABLE, the
other thread stops execution until the condition == TASKS_AVAILABLE,
empties the list and changes condition to TASKS_COMPLETED thus halting
itself... I love mutli threading... reminds me of my days long ago when
I was a teletype tech... locks are like the clutches in the teletype
machine syncronizing the different functions in the machine... when an
application multi threads you truely have a macahine.... (Lon snaps
back to reality)
On May 9, 2006, at 11:48 PM, Lon Giese wrote:
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:
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