On Nov 28, 2008, at 1:48 PM, John Love wrote:
Reference page 43 of Apple's MultiThreading.pdf.
For what it's worth, a reference to a page in a PDF isn't a convenient
way to direct folks to a part of the docs. If I were to try to direct
somebody to the same docs, I would have directed them to:
http://developer.apple.com/documentation/Cocoa/Conceptual/Multithreading/CreatingThreads/chapter_4_section_6.html
Anyway...
I conclude from this page that the preferred, if not only, way to
have the main thread stop the background thread is through KVC.
KVC is in no way central to what's illustrated on that page. The only
reference to KVC is the use of the -setValue:forKey: and -valueForKey:
methods which are used to store and access a value in a dictionary.
It could have used the -setObject:forKey: and -objectForKey: methods
just as easily, and they aren't KVC.
KVC is not a solution to the problem you're considering.
Before I continue to inflict more pain on myself, why can't I simply
toggle the value of an instance variable of the class' interface
from the main thread and have the backgroundThreadRoutine look at
the same variable and break out of the background thread if its a
certain value?
Well, you can, with caveats.
The first caveat is: is your background thread awake and checking the
variable on a regular basis so it can notice the change? Or is it
blocked? If it's blocked, how is it blocked?
Depending on what your background thread is doing, there's a slim
chance that the compiler has made an incorrect assumption. It may
have assumed, based on a narrow view of the code, that your instance
variable couldn't change over the course of backgroundThreadRoutine.
It might then apply an optimization where it reads the value once at
the start of that routine and then caches it in a register. From that
point on, it might never check the real instance variable again and
only rely on its cached copy. Setting that instance variable to have
the "volatile" qualifier would work around that. However, volatile is
often unneeded because any non-trivial function will prevent the
compiler from making that particular optimization. You should use it
as a last resort.
Should I conclude that this class variable is in the main thread and
is not accessible by the background thread?
No.
If KVC is the only approach for inter-thread communication, I'll
press on.
Again, KVC has nothing to do with any of this. KVC is just a way to
call methods (property accessors). It picks which methods to call
based not on compile-time code but run-time data. That's it.
I think what you're failing to understand about the technique on that
page is:
1) It uses the thread dictionary to store a "should exit" flag. The
thread dictionary is a Cocoa implementation of thread-specific storage
(a.k.a. thread-local storage). So, each thread automatically has its
own private dictionary of key-value pairs which is independent from
any other thread's.
2) there's code which isn't shown which a) installs a custom input
source on the run loop, and b) when that input source is "tickled",
the handler sets the "should exit" flag in the thread dictionary.
This can be somewhat simplified using the -
performSelector:onThread:withObject:waitUntilDone: method introduced
with Leopard. Using that method, you don't have to implement a real
custom input source. You can just use a dummy NSPort object which
isn't connected to anything. (The only reason to use that port object
is to guarantee that the run loop has some input source and doesn't
exit immediately.) The main thread doesn't need to know about nor
have a reference to this "input source" and you don't have to
implement a handler for it. Instead, just implement a method which
sets the "should exit" flag in the thread dictionary and have the main
thread pass that selector to your background thread using -
performSelector:onThread:withObject:waitUntilDone:.
Regards,
Ken
_______________________________________________
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to [EMAIL PROTECTED]
