Rockbox mail archiveSubject: Re: Proposed changes to threading API
Re: Proposed changes to threading API
From: Nix <nix_at_esperi.org.uk>
Date: Tue, 08 Aug 2006 23:16:00 +0100
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 SteenwinkelReceived on 2006-08-09