dev builds
themes manual
device status forums
mailing lists
IRC bugs
dev guide

Rockbox mail archive

Subject: Re: potential bug report
From: Björn Stenberg (
Date: 2002-06-12

Greg Haerr wrote:

> A quick review of the source shows that, although not a bug yet, the
> code in firmware/drivers/ata.c::ata_read_sectors() won't work if the
> count parameter is ever called with a value != 1.

Right, we haven't tested with >1 sector reads. Nice spotting, we're fixing
it now.

> BTW, I'm trying to understand exactly how many threads are running in
> the current version. Is it just the mpeg_thread, or is there a seperate
> UI/button thread?

Currently there are three threads in use:

- Main/UI thread
- Mpeg thread
- Scroll thread

The buttons are polled in interrupt context (every X timer tick) and
events are posted to a queue, which is read by the main thread.

> I ask because the ATA disk routines have mutex sections, and was
> wondering whether the entire disk subsystem was built to work using open
> "files" from multiple threads... Very cool low-level code, BTW.

Thanks. Yes, we are today opening and reading files in both the main
thread (playlist files) and mpeg thread (mp3 files), hence the mutexes.

> In the kernel.c mutex_lock function, there's no STI/CLI pair around the
> mutex, is this because there's no preemptive scheduling?

Exactly. We delierately chose to use cooperative scheduling to keep
complexity and reentrancy issues to a minimum.

> I see that the queue_post routines have it, and I assume that's because
> those routines can be called from a bottom-half interrupt routine (which
> aren't scheduled, just interrupt-driven?

Correct again. :-)

> I haven't seen yet what gcc emits for SH1, but for some systems,
> ++m->count is much faster than m->count++. (same for decrement)

About optimisation in general, I have instructed people to not think about
instruction-level optimisation when writing C code, instead focusing on
making the code simple and straight-forward, just like any normal C code.

Your example is not complex or counter-intuitive, so it's not a problem,
but in general I prefer simple code over fast code. Most code doesn't need
to be fast and thus we gain more from it being simple.


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