Messages in this thread | | | Date | Thu, 22 Nov 2007 19:07:24 -0600 | From | Robert Hancock <> | Subject | Re: Use of mutex in interrupt context flawed/impossible, need advice. |
| |
Leon Woestenberg wrote: > Hello, > > > I'm converting an out-of-tree (*1) driver from binary semaphore to mutex. > > Userspace updates a look-up-table using write(). The driver tries to > write this LUT to the FPGA in the (video frame) interrupt handler. It > is important that the LUT is consistent and thus changed atomically. > Note that it is not important that the LUT is updated each interrupt. > > The current approach is to try-down()ing a binary semaphore in > interrupt context, and write the LUT to the FPGA if the semaphore was > down()ed, do nothing else. > The write() down()s the semaphore as well before updating the > in-driver-copy of the LUT, then up()s it again. > > I understand this design is not clean (*2), and not even possible with > mutexes, as mutex_trylock() is not interrupt safe. > > My current approach would be to have userspace write into a shadow > copy, and use a spinlock to update the live copy. The interrupt then > would try a spinlock.
Unless this update into the FPGA takes a significant amount of time, I wouldn't bother with that complexity - just do spin_lock_irq/irqsave on that spinlock.
Using a trylock for this rather sucks since the behavior is entirely non-deterministic. It could take a really long time in some cases for the trylock to ever succeed.
> > My feeling is that we have a valid use of mutex_trylock() in > interrupt context; "i.e. update LUT if we can do so consistently and > in time, or not at all". > > I would like to know why this is not so, and if someone has a cleaner > proposal than the "try spinlock" approach?
-- Robert Hancock Saskatoon, SK, Canada To email, remove "nospam" from hancockr@nospamshaw.ca Home Page: http://www.roberthancock.com/
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |