PSP_THREAD_ATTR_VFPU and multiple threads

[gauri]

I've bumped into unexpected problems with multiple threads having PSP_THREAD_ATTR_VFPU attribute set.

Let me describe the setting... I have main thread and, say, 8 workers. All of them have the attribute set (potentially). In the main thread i do rendering stuff, worker threads are created for sound processing (one per channel).

So, if I have the attribute set for all threads, the code breaks, having sudden hangings of main thread, or screen messed up (looks like buffer pointers go wrong somewhere inside). I can still terminate my program with "Home" killer, though. If I remove the attribute flag from worker threads, everything goes smoothly and without any problems.

Is there possibly a limit for having threads with PSP_THREAD_ATTR_VFPU attribute set? Some kind of buffer overrun happens? I so not see any other reason this could be happening since all the threads do nothing except yielding the control to each other.

[J.F.]

Such a thread needs a MUCH larger context, which I would guess is pulled from the stack. The stack has a default size that may be overflowing after X number of threads set to use the VFPU. You might try increasing the size of the stack to see if that fixes the problem. The macro that goes in the main file is

Code: Select all

PSP_MAIN_THREAD_STACK_SIZE_KB(256);

where 256 would be changed to whatever stack (in KB) you want. Try different sizes and see what happens.

[gauri]

Unfortunately, it still fails. The screen is still flickering. :-(

[J.F.]

What size are you setting the heap to? I've seen programs that set the heap manually, and setting it wrong prevented threads from being created. SNES9xTYL is that way.

[gauri]

I use default settings for the heap, e.g. I set nothing. :-)
Thread creation does not fail, the threads seem to work.

[J.F.]

Well, unless someone has run into this before, all we can do is just keep making suggestions. :) If it isn't a secret or something you want to keep closed, you could post the code you're doing this with. Maybe it's something else that's making it crash that is only peripherally related to the VFPU.

My next guess is maybe you could try increasing the size of the stack of the created threads. Maybe the threads are created with a stack too small to handle VFPU. The stack size for the created thread is the fourth arg passed in the function to create the threads.

[Insert_witty_name]

I've had similar effects once before.

I put it down to the fact that the kernel saves and restores the VFPU registers when switching threads.

It's also probably why the VFPU param is optional when you create a thread.

Best bet is to limit VFPU capable threads to as few as possible.