Artificial intelligence loop - prevent the application from not responding

Question

Level 1

0 points

Artificial intelligence loop - prevent the application from not responding

Hello there! I'm trying for fun and for knowledge to build up a simple "bot" which takes informations from the environment (and thus not only from the application itself).

The first attempt to build it was to create a "mainLoop", containing some conditions with sub-loops, going into loop via

- (BOOL) mainLoop {
loop:;
 if(/* conditions to exit */) return NO;
 // my conditions with subloops
 goto loop;
 return YES; // will never be cast
}

The problem is that as soon as I start the program, it will stop responding.
Is my approach wrong? How would you structure it?

Thanks

iMac 3.06Ghz, Mac OS X (10.6.2), MacBook late 2008

Posted on Dec 23, 2009 6:41 AM

Reply

Answer 1

elegos Author

Level 1

0 points

Dec 25, 2009 3:00 AM in response to etresoft

I whish I could select your reply as "helpful", but there is only the "Solved" one, I'm near the solution 🙂

First of all: Merry Christmas 🙂

Second: AFAIK the @syncronized block of code forces all the threads to wait it, am I right? My environment readings take some milliseconds and repeat each second, they may affect the general performance.

For the NSThread: I must create an NSAutoreleasePool, am I right? Also, the readings are made by other classes than the main one. AFAIK I can't use them in another thread than the one I'm running them (I should initialize a new instance of them), how can I wrap their variables into an NSDictionary continuously? Global variables? How can I use them?

Thanks 🙂

P.S.
Why system monitor says my application is using one thread, even if I enter an infinite loop within a new thread? Shouldn't it count as 2-threads application?

Reply

Answer 2

etresoft

Level 8

46,482 points

Dec 26, 2009 8:46 AM in response to elegos

elegos wrote:
Second: AFAIK the @syncronized block of code forces all the threads to wait it, am I right?

Yes. Use them sparingly.

My environment readings take some milliseconds and repeat each second, they may affect the general performance.

You only need the @synchronized block to provide mutual exclusion with your shared variables. Your thread can take as long as it needs to gather the readings, but when it goes to store them in the shared variable, that is when it should use the @synchronized block.

I don't know what is taking place that would take milliseconds to "gather the readings". If you have some external data source, you may need yet another thread just to read data from that source. I don't know the details. Having updates once per second is no big deal. In any event, this is the simplest mechanism. Start with it and see how it works. If you find need something better, at least you are starting from a working, albeit slow, system instead of from zero.

For the NSThread: I must create an NSAutoreleasePool, am I right?

Yes.

Also, the readings are made by other classes than the main one. AFAIK I can't use them in another thread than the one I'm running them (I should initialize a new instance of them),

I don't know exactly what you mean by "readings". If, for example, you had data coming in over a relatively slow USB or wireless link, you may need a separate thread just to handle that data. I don't know. If your data was coming in over a remote TCP/IP or distributed objects link, then that can be handled in the main thread.

how can I wrap their variables into an NSDictionary continuously? Global variables? How can I use them?

Yes, they are global, or maybe static, variables. If you only need to maintain the latest reading, you can use a dictionary to key each individual reading with each latest value. If you need to track all values, you may need an array - or perhaps your dictionary value is an NSArray. If you put everything you need to share into one dictionary, you can easily perform the @synchronized directive against that dictionary.

Why system monitor says my application is using one thread, even if I enter an infinite loop within a new thread? Shouldn't it count as 2-threads application?

I don't know. Perhaps system monitor only counts the number of NSRunLoops. Almost any Cocoa program I've seen has at least 3 threads just to start with.

Reply