> : 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 argument. Dan
