Re: Thread Question
Re: Thread Question
- Subject: Re: Thread Question
- From: Mark Onyschuk <email@hidden>
- Date: Wed, 28 Apr 2004 06:07:57 -0400
On Apr 27, 2004, at 10:54 PM, email@hidden wrote:
Message: 4
To: Cocoa Dev <email@hidden>
From: Dave Keck <email@hidden>
Subject: Thread Question
Date: Tue, 27 Apr 2004 21:43:35 -0400
Hey,
after following along with these posts on NSTimers and NSThreads, I
remembered a question I've had for awhile now...
Say I have a thread, myThread, and I also have the main thread,
mainThread. I also have a method, myMethod:
Question 1: Is it OK to call myMethod from myThread? Is myMethod within
the "scope" of myMethod (assuming all this code is in the same class)?
Question 2: If Question #1 is "yes": is it safe to call myMethod from
both mainThread and myThread, possibly at the same time (if, say,
mainThread and myThread both had loops that called myMethod)? (Would I
have to use NSLocks for methods too?)
Question 3: If it is OK to call myMethod from both mainThread and
myThread: what happens when I do? Does it call the method by the same
address if I were to call it from mainThread and myThread, or does each
thread have its own "copy" of each method that it calls?
Thank you very much for any insight!
These questions are all related in a sense, so I'll tackle them as a
group.
When you spawn a new thread inside an application, all you're really
doing is spawning another independent execution context (with its own
local stack frame) inside your same process. This execution context
shares all global variables and all code with the original thread. It
can call through anything that it can grab a reference to - like
Objective C class methods or specific instances that are either passed
to the thread, stored in global variables, or somehow discoverable from
class methods (eg. [NSFileManager defaultManager]).
Now, given this definition, you certainly can call a single method from
different threads simultaneously and there's nothing inherently wrong
with this. Whether it's correct or not depends entirely on how the
method itself is written.
If the method acts as a function where all of the data it works on is
passed by the caller, and only local variables are used in computation
(ie. variables that are stored in the calling thread's own stack frame)
then any number of threads can call the method simultaneously and not
interfere with each other. No locks are required for this sort of
method.
If on the other hand, a method operates on instance variables, on
global variables, or other data that is shared between threads, then
you have to take precautions and use locks to allow only one thread at
a time to operate on that data. Otherwise reading and writing data
becomes unpredictable. When writing multi-thread accessible objects,
you have to have a good understanding of what data your code touches,
and what defines a consistent state for that data. Use locks to protect
both the data and its consistency, and you're fine.
Now, protecting data and consistency is a potentially tricky bit of
business to get right, so often it's nice to constrain your threading
to cases that are less troublesome. In the case of object-oriented
systems, this is a little bit easier to do when you constrain threads
to operate on their own object instances or independent sets of
objects. Here the thread and it's associated objects can be viewed as
their own independent light-weight 'process' or machine.
In my own threaded programming, I tend to minimize cases where objects
themselves are the target of calls from multiple threads of execution
and factor out the job into separate thread + object-sets that can work
more independently as I describe above. Where these jobs do interact, I
try and keep it purposefully uninteresting - I'll use queues to pass
data for jobs between, say, a worker thread and a main thread of
execution, for example. Here the shared object (the queue) and the
locking required to keep its data and state consistent is pretty well
understood, and arbitration between threads can be managed cleanly with
helpers like NSConditionLock.
Mark
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.