dev builds
themes manual
device status forums
mailing lists
IRC bugs
dev guide

Rockbox mail archive

Subject: Re: Proposed changes to threading API

Re: Proposed changes to threading API

From: Daniel Ankers <>
Date: Tue, 8 Aug 2006 10:16:49 +0100 (BST)

> : 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);
> Looks like lots of duplicated code. Why not have all this handled
> in the create_thread_on_core function, and/or in the threading
> library only. Then you'll always get a thread when asking for one
> and not have to write code to handle a failure case every time.
> The main vs coprocessor request could be handled with a flag
> argument to the standard create_thread routine. Also, why
> a special remove_thread_on_core routine?
> Perhaps I need a quick tutorial on the kinds of things that need/want
> to be handled on multiple cores.

Hi Greg,
I'll address your points in reverse order. I'm only a novice programmer,
so please forgive me if I get any terms wrong!

I think the plan is that it will be rare to start a thread on the second
core - it would probably be dedicated to audio and/or video decoding. As
there is no cache snooping between the cores on the PP chips there will be
a number of restrictions on tasks that need to communicate across the
cores. The vast majority of the time, a process creating a thread will
want that thread created on the same core.

The requirement for a remove_thread_on_core routine isn't obvious, so I
guess I should have explained that first.
My original plan was to just have an extra variable for each thread to say
which core it was running on and not change all the variables to arrays.
This would have meant no changes that were visible outside the threading
code, but would also have meant that switch_thread spent time searching
for the next thread on that core. Since switch_thread gets called a lot,
it needs to be as fast as possible.
So I changed the variables to arrays, which means that each core has its
own threading namespace (i.e. there can be a thread number 1 on each
core.) The routine to remove a thread therefore also needs to know which
core to remove the thread from.

I am against adding a flag to create_thread (and remove thread) to say
which core the thread should be on because I am lazy!
As I said, most of the time threads will be created and removed on the
same core as the thread which creates them. It seems more trouble than
it's worth to change all of the code in Rockbox, all of the documentation
and to break any patches in Flyspray or independently developed plugins
when there is another way.

As regards the duplicate code in the example which I gave, I agree with you.
Maybe a better way to do it would be to have create_thread_on_core try to
create a thread on the requested core and then the current core, and
return a struct containing the core the thread was created on and the
thread number, or -1 and -1 to indicate that the thread could not be
created. remove_thread_on_core would then take that struct as its

Received on 2006-08-08

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