On Mon, 7 Aug 2006, Daniel Stenberg wrote: > Gosh. Abandoning the cooperating multi-tasking of current Rockbox will > open all gates to hell and lead to no good. We'll need a bazillion > locks, mutexes and similar things and then still have to debug for > thread-related problems and dead-locks for many months/years ahead.
True concurrency may eventually require some sort of simple locking in any case, but the... strongly separated nature of much of what Rockbox does hopefully means that this can be kept to a minimum (e.g. if one core does nothing but audio, not much will need locking: if somehow the audio decoding gets split across cores, the only things which will need any sort of inter-thread cooperation are still only things directly related to sharing the decoding load, and so on). I think in the end it might well be a good idea to move to decoding on both cores, simply because otherwise one core will *still* be mostly idle most of the time, and IIRC the CPU boost applies to both cores at once so we'd be wasting a lot of power spinning an idle core. -- `We're sysadmins. We deal with the inconceivable so often I can clearly see the need to define levels of inconceivability.' --- Rik Steenwinkel
