From: Andrew Hart <ahart_at_dim.uchile.cl>
Date: Mon, 07 Aug 2006 10:35:15 -0400

At 05:18 07-08-2006, you 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
>...
>
>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.
>
Excuse me, but I've got two daft newbie-type questions here that are
more for my own education than anything else.

Firstly, might it be better to declare create_thread and
remove_thread using #define directives and removing the existing
functional definitions instead of using the suggested changes to the
existing implementations? This would eliminate an extra function
call. Oh, but maybe create_thread and remove_thread are not called
that often so perhaps speed isn't a concern here. Can anyone put me straight?

Secondly, could it also be useful to have a function or #define that
reports how many cores there are on the existing platform? That way,
it wouldn't be necessary to check for specific players and/or models
when deciding whether to start a thread on a second core.

Cheers,
Andrew.
Received on 2006-08-07