From: Jonathan Gordon <jdgordy_at_gmail.com>
Date: Mon, 7 Aug 2006 19:45:26 +1000

is there any reason why the thread has to stay on one core?
And on the topic of threads, what about changing to prioritising
threads? especially the audio thread.
And lastly, put in a schedular so threads dont have to explicitly
yield (maybe this will stop the problem where you have to reset if the
ui thread crashes but audio/backlight still work?)

On 07/08/06, Daniel Ankers <dan-rockbox_at_weirdo.org.uk> wrote:
> Greetings all,
> I have been looking at using both cores on PortalPlayer based devices
> (iPod, Sansa E200, iRiver H10.)
> I think that supporting this is going to require changes to the threading
> API so that threads can be run on both cores.
>
> I propose:
> 1. Changing the variables in thread.c such as num_threads to be arrays
> (e.g. num_threads[NUM_CPUS]) I don't think that any of these variables
> get referenced from outside thread.c apart from by the debugging menus.
>
> 2. Adding functions to create/remove a thread from a specific core:
> int create_thread_on_core(unsigned int core, void (*function)(void),
> void* stack, int stack_size, const char *name)
> void remove_thread_from_core(unsigned int core, int threadnum)
>
> 3. Changing the existing create/remove_thread to be:
> int create_thread(void (*function)(void), void* stack, int stack_size,
> const char *name)
> {
> return create_thread_on_core(CURRENT_CORE, function, stack, stack_size,
> name);
> }
>
> void remove_thread(int threadnum)
> {
> remove_thread_from_core(CURRENT_CORE, threadnum);
> }
>
> CURRENT_CORE would be the core that the thread is being created from.
>
> This would mean that the only code changes necessary outside of thread.c
> would be in the debug menu.
>
>
> What does everyone think?
>
> Dan
>
>
>
Received on 2006-08-07