Threads

Hi all,

I've got some general questions and gripes about threads.

Q - What is the priority parameter for. Are there any suggestions on what a good value is?
Q - Do you need to fill in the stack size or can this be 0. On windows leaving this 0 means the OS will set a default size. Is this the case with libogc? Also if I'm not passing an argument to the thread should I leave this as zero.

Now some gripes. Maybe this is because I'm used to the high end power of a Linux/Windows PC but I ran two threads and it pretty much crippled my main(){} loop. The processing in the threads was not very intense. I also tried to follow a pretty standard technique of sleeping for x milliseconds on the unimportant thread within the thread loop. Doing this seemed to cause the thread to freak and lock up.

Any advice is appreciated as I've not had much luck using libogc threads.

Thanks
scanff :)

The priority parameter decides what threads will run if more than one is in the runnable state. Only those with the highest one will run. No, those with lower priorities are never going to run.
Of course, threads that isn't runnable (like waiting for I/O) doesn't count against the other threads.

Priority, shagkur has told me set that to > 128 for time critical threads, and < 128 for anything else. Main thread runs at priority of 80 and gets a stack size of 128K. So I set some threads below 80, as the other threshold. The default stack size for other threads if you use 0 is set to 8K, be aware of this so you don't get a stack overflow. Two threads set with the same priority get time sliced, theoretically at least.

usleep should work as you are expecting. You can also use VIDEO_WaitVSync(). I have quite a few threads, and they all seem to happily get their work done, so long as there's a set delay in each of the threads, including the main thread. Otherwise one thread (I would assume with the highest priority) will hog resources.

As for performance, not sure what you're trying to do in your threads. Of course you're limited to the performance of the Wii's CPU, but that being said there's a lot you can do with it. In the Snes9x GX emulator, for example, the main thread does the emulation, and there are two more threads, one for each of video and audio. In the menu, there's a thread to initialize devices, monitor devices, monitor menu changes, get user input, check for version updates, draw the menu, update loading progress, etc. My thread priorities differ, not sure what impact it has - but I have audio/video threads at 150, and a less important "value checker" thread at 40, with a 1/2 sec sleep.
All these threads seem to get along well enough to not affect the user - but yes, I've seen what you're talking about, when you don't have your threads setup properly.

Also be aware of using SuspendThread, ResumeThread, JoinThread, etc. They can come in handy.

Hope this helps!