On Mon, 27 Oct 2008 16:44:17 +0100 "Leon Ljunggren" <leon.ljunggren@xxxxxxxxx> wrote: > To ensure that this doesn't happen I'm trying to use > spin_lock_irqsave, but I'm getting rather unexpected results. First of > all it doesn't seem to disable the interupt, the interupt function is > still called and secondly it just seems to ignore the lock. Even if > avr_read has aquired lock2 and then gets interupted (which it > shouldn't since interupts should be disabled, right?) avr_interupt > will not care and still call the write/read functions instead of > blocking as expected. Are you running in a uniprocessor environment, or with multiple CPUs? spin_lock_irqsave() only disables interrupts to the current processor, in order to avoid the following deadlock situation: If your code got interrupted by something running on the same CPU, and that interrupt code tried to acquire the same lock, then it'd spin forever because the interrupted code would never run to the point of releasing it. When the interrupt code runs on another CPU, either processor can simply wait for the other to finish - no deadlock. >From your description, I'm not quite clear on why you have two locks rather than just one. In fact, it looks dangerously like your "flag" variables could be uninitialised. Is there any reason not to just have a single lock protecting the consistency of the "data block and data pointer" pair? Disclaimer: I'm also very new to this, but replying has been a useful learning exercise for me... Thanks, Tom -- Thomas White Department of Materials Science and Metallurgy Electron Microscopy Group (PhD Student) University of Cambridge / Downing College -- To unsubscribe from this list: send an email with "unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx Please read the FAQ at http://kernelnewbies.org/FAQ
