[DaGuy]

Observe the following code:

Code:
 [self stopReading:nil];
    
   while(state!=0){
       NSLog(@"Waiting for stop state.  Current State = %i", state);
    }

The stopReading: method executes asynchronously in its own thread. It's job is to stop a process and to then set an instance variable named "state" to "state=0" to indicate that the process has stopped. This works fine, since I can verify a responsive UI while it the thread executes.

Now here it's were it gets a bit more interesting. The while loop below never exits.
This is because the state variable in question is never updated in the background. My guess is that the loop starves the background thread.

I find this a bit odd since I thought that background process was going to get some CPU time.

Any comments?

Thanks!

[Brass]

Edit:

OK, looks like I was completely off track.

[Uncle Skeleton]

no, I do use threads and that is definitely wonky. I use shared instance variables all the time (most commonly BOOL cancelled = NO;), and I also am acutely aware that different threads in the same app do not have memory protected from each other.

what was the exact code you used to branch off the new thread? What happens when you fill stopReading with NSLogs? or when you debug and put stop points in the stopReading thread? are you sure that method is actually running?

also, what if "state" is already used by something. try another less likely var name

[Ghoser777]

I'd have to see how your spawning your thread and everything, but the only thing that comes to mind is: are you properly locking your global instance variables when you're changing them? I think weird things can happen if one thread is reading a variable at the same time your changing it.

Matt Fahrenbacher

[Gametes]

Using the debugger, with a breakpoint in your stopReading method where it is supposed to set state to 0, does it ever get there?

[DaGuy]

Let me do some additional checking. I'll post again soon.

[DaGuy]

I screwed up. Cocoa is beautiful!

The stopReading: method doesn't set the "state" instance variable. My boo boo. The variable is set by an NSTimer which polls several combinations of instance variables to determine the application's state. The NSTimer is the heart beat of the state machine.

The problem is that the timer runs in the main thread. Since the loop also runs in the main thread, it blocks the timer from firing and updating the state variable.

Multithreading is a tricky business. Sorry guys. I should've paid more attention. I will run the timer in a different thread.

[itai195]

Yes, the timer should be in another thread. While we're at it, one should never write loops like the above, because they're just wasting CPU cycles (this is called busy waiting). I'm assuming you probably just wrote that for debugging purposes though. It's also advisable to synchronize access to that state variable, since it's shared by multiple threads...

[Gametes]

In my threads, I have a while loop that exits when shouldThreadDie = YES. Other functions check up on isThreadRunning from time to time or in while loops of their own.
Is this an acceptable method, or am I wasting time too?
What's the recommended way?

[itai195]

The general idea is that a thread that's doing nothing but constantly polling a shared variable should be put to sleep and be notified when the variable changes. The way you usually do this is with a monitor (a condition variable and a lock). The pseudo-code is something like so:

Code:
acquire lock
while not CONDITION
   wait on shared variable
do your stuff...
...
...
notify one or all threads waiting on shared variable
release shared variable's lock

What this lets you do is go to sleep while the variable remains unchanged. Conditional variables allow a thread to add itself to a wait queue AND to release a lock atomically, so a thread that has to wait can simply sleep and release the lock, allowing other threads to attempt to acquire the lock and do something useful with the variable. When another thread has changed the variable, it should notify one or all of the threads waiting on the condition. When the above thread is awakened, it would reacquire the lock and then resume execution within the while loop.

See Apple's documentation for information about how this is implemented in Cocoa.

Here's an example in Java, though please note that Java's implementation is a little weird because every object implicitly has a built in monitor:

Code:
... in a thread class ...

// A shared variable
public String whereAmI = null;

public void run() {
   synchronized (whereAmI) {
      while (whereAmI == null)
         whereAmI.wait();
      System.out.println ("I know where I am!");
      System.out.println ("I'm in " + whereAmI);
      whereAmI.notifyAll();
   }
}

Keep in mind that this is a pretty useless thread. There are also some situations where you can change the while above to an if, depending on the type of monitor being used and the type of condition you are waiting for.

[DaGuy]

Thanks for the discussion. I definitely got a more educated perspective going forward.