Rockbox.org home
release
dev builds
extras
themes manual
wiki
device status forums
mailing lists
IRC bugs
patches
dev guide



Rockbox mail archive

Subject: Re: Proposed changes to threading API

Re: Proposed changes to threading API

From: Daniel Ankers <dan-rockbox_at_weirdo.org.uk>
Date: Mon, 7 Aug 2006 17:40:26 +0100 (BST)

> At 05:18 07-08-2006, Andrew Hart 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?

create/remove_thread aren't called very often. Do people have any
preference for or against using #defines over functions in this case?

> 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.

The code which I have knocked together to test all this has NUM_CORES
defined in config.h.
With regards to creating a thread on the second core, there is no
guarantee that this will be available even on PortalPlayer machines, so
the code to create a thread on the second core would be something like:

my_thread = create_thread_on_core(COPROCESSOR, my_function, my_stack,
sizeof(my_stack), my_thread_name);
if(my_thread == -1)
  my_thread = create_thread_on_core(CPU, my_function, my_stack,
sizeof(my_stack), my_thread_name);

Dan
Received on 2006-08-07


Page was last modified "Jan 10 2012" The Rockbox Crew
aaa