ofcourse you’re not going to create threads for the sorting, you already have a bunch of worker-threads laying around 
My thoughts are as follows: if you have the ability to allow two or more threads to control your game (update/render), go for it. But let the OS decide which thread runs on which core. However, if you can’t control which thread goes on which core, then a problem arises. If the OS asigns both threads to the same core, they won’t run simultaneously. Say this is the OS’s thread queue, in which case the OS assigns each thread to a differant core:
CORE 1:
Process 1
Process 2
Process 3
Process 4
Process 5 (Your game’s UPDATE thread)
Process 6
Process 7
Process 8
CORE 2:
Process 1
Process 2
Process 3
Process 4
Process 5
Process 6
Process 7 (Your game’s RENDER thread)
Process 8
This would be great, however, if the OS assigns your threads to the same core, it would be like your game is running on a single core system, each thread would have to wait for the process ahead of it to finish, and would have to wait for your other thread to finish. Here’s how the OS’s thread queue might look in that situation:
Process 1
Process 2 (Your game’s RENDER thread)
Process 3
Process 4
Process 5
Process 6
Process 7 (Your game’s UPDATE thread)
Process 8
My point here is, if you can’t control which thread goes on which core, just use a single-thread game, or it may run slower if your threads are running on the same core (or even 3 are on one core, and 1 on the other, etc).
Take the Xbox 360, they have “3 symmetrical cores running at 3.2 GHz each” and “2 hardware threads per core; 6 hardware threads total” (source: http://hardware.teamxbox.com/articles/xbox/1144/The-Xbox-360-System-Specifications/p1). This means they can run 6 threads sumultaneously, however, it’s using custom hardware, and the hardware is dedicated specifically to the game. So the 360 obviously makes use of these 6 threads running at the same time. I bet the 360 has the ability to choose which thread goes on which core, or the 360 automaticly assigns each new thread to a core which does not already have a thread running, meaning it cannot allocate more than 6 threads. Note that this is only my guess, I have NOT confirmed this.
elias, i seem to remember reading that, but I can’t find it. Would you mind linking me please ?
DP
sorry to burst your bubble but with any semi intelligent thread assigner would prefend the situation that you describe from arrising. obviously that render and update thread will take a significant amount of a bite out of the core/cpu resources and figure out on it’s own that it would be better to assign it to separate cpu if it can’t figure it out its probebly not nessasery. If theres an other program bound to the other cpu already and stresses it it will be more efficient to have it all run on one core. Perhaps some hint’s that one thread should be or not on the same core/cpu would allow for quicker discovery or could render optimalisation towards memory share or what not but that all is still a whole differend approuch from tieing it to one cpu.
the same issues that arise from your approach are quite similair to the problem arised with hardcoded memory spaces and multi programs and the resulting conflicts.
//edit
xbox… console games/programms can pull this off because they are actually aware of everything going on, on the machine pc/computerprograms are not and should gracefully share/claim resouces. This also includes cores.