Ingo Oeser wrote: >Hi Tim, > >On Sun, May 12, 2002 at 12:24:57PM +0200, Tim Goetze wrote: >> nevertheless, i went looking at the other archs and very much to my >> surprise found corresponding code for ppc and sparc for example. to >> my surprise because i assume it to be unused, otherwise there'd be an >> implementation for every arch. i'm still thinking whether relying on >> this unused code is a good idea. > >It looks safe in some cases. Most of them just implemented it, >because it is possible and not included in the actual kernel code >if never called (because it's inline ;-)). Some of these >generalized the atomic inc/dec and test with them.
basically i do expect them to work. on sparc fe, atomic_inc_return is actually the same code as atomic_inc, ditto for the rest of the suite (on sparc). i'd have to dig a little deeper into ppc assembly to figure out how the multi-instruction atomic_* work there without being preempted. >> can you specify which architectures use privileged instructions for >> this purpose? > >Architectures, which use cli/sti to implement it. This is almost >always an privileged instruction, so no user can stall interrupt >processing of the kernel on sane architectures. arm and cris come >to mind. yup, that's a problem. but since they use cli/sti even for simple atomic_inc, i've already excluded them from the list of possible ports ... ignorance on my part, but ignorance on the part of the respective cpu designers as well imo. >Use trylock and spin for a while to simulate "spinlocks" and >avoid the schedule. But atomic operations are always better, it's pointless to spin on a pthread_mutex_trylock in a SCHED_FIFO thread on a single-processor system if there are no SCHED_FIFO threads running at higher priority, which should be the case for an audio thread. atomic operations aren't just the better, they are the only choice in this case imo (unless you install per-thread fifos). thanks, tim
