You talk about "multithreading difficulties" but what difficulties are you actually talking about? In a way you're citing a phantom problem which may not even exist. The real challenge is one you make for yourself - if you are absolutely determined to get every last drop of power out of a piece of hardware, that does involve using the hardware to best effect, but that also widens the gap between the most powerful machine and the least powerful. The implication of this is that if you have a game that really makes the most of a PS3 (for example), you can't really run it on a cheap cellphone anyway, so your problem is no longer "how can I get 1 program to work across very different hardware" but becomes "how can I implement 1 game idea several different ways so that it works on differently powered hardware". The threading issue becomes less relevant then.
While a library like SDL provides a cross-platform wrapper API for threading, I think it would be naive to assume that this leads directly to easy development of games across vastly different platforms (desktop / mobile).
Easy development of games - sure. Optimal multithreading, no. But you don't need multithreading to make games. To make high performance ones, it certainly helps. But many great games run in a single thread.
What is the best way to tackle developing in this way (given any cross-platform threading API) considering the following:
- different numbers of cores
- vastly different processing capabilities per core
- A generally different systems architecture with eg. different latencies for cache, RAM , and I/O access
Instead of trying to assign systems to threads, assign tasks to threads. Give each task the data it needs to run and farm the tasks off to whichever hardware is available. Usually you'll have some sort of thread pool to abstract away the various cores or processors, and a task manager which has a queue of tasks and yields them up to the various threads when the thread signals that it is finished the previous task and is ready for a new one. Hardware with more cores will obviously complete the tasks more quickly and be able to render more rapidly. Specialising this system to work optimally on systems with different characteristics becomes an advanced optimisation problem, but can be based on certain heuristics (eg. a task which doesn't need to return much data can easily be pushed to a different processor but one with a lot of data to return might need to be kept local).
However, decomposition of game features into discrete tasks is quite a complex matter and often not worth the effort unless you are very sure that you need the performance, so most won't even attempt it.
Some further reading:
http://www.gamasutra.com/view/feature/1830/multithreaded_game_engine_.php - see the 'data parallel' section. With this model the data is split across several identical tasks and farmed out to individual threads.
http://software.intel.com/en-us/articles/designing-the-framework-of-a-parallel-game-engine/ - quite dense, describes things at the OS level rather than the game level.
http://drdobbs.com/high-performance-computing/216500409 - not game specific, but completely relevant in terms of telling you how you need to divide up the tasks.
http://www.itfgaming.com/news/tech-focus-crysis-2-and-the-future-of-cryengine-3 - half-way down this interview is an anecdote about how they migrated to a task based system.
