Rockbox.org home
release
dev builds
extras
themes manual
wiki
device status forums
mailing lists
IRC bugs
patches
dev guide



Rockbox mail archive

Subject: 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 Steenwinkel
Received on 2006-08-09

Page was last modified "Jan 10 2012" The Rockbox Crew
aaa