|
Rockbox mail archiveSubject: Re: potential bug reportRe: potential bug report
From: Björn Stenberg <bjorn_at_haxx.se>
Date: Wed, 12 Jun 2002 11:21:06 +0200 (MET DST) 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. -- BjörnReceived on 2002-06-12 Page template was last modified "Tue Sep 7 00:00:02 2021" The Rockbox Crew -- Privacy Policy |