On Thu, 2010-07-29 at 22:42 -0400, Andy Walls wrote: > On Fri, 2010-07-30 at 05:17 +0300, Maxim Levitsky wrote: > > It is prefectly possible to have ir_raw_event_work > > running concurently on two cpus, thus we must protect > > it from that situation. > > Yup, the work is marked as not pending (and hence reschedulable) just > before the work handler is run. > > > > Maybe better solution is to ditch the workqueue at all > > and use good 'ol thread per receiver, and just wake it up... > > I suppose you could also use a single threaded workqueue instead of a > mutex, and let a bit test provide exclusivity. With the mutex, when the > second thread finally obtains the lock, there will likely not be > anything for it to do. Mutex there is for another reason, to protect against decoder insert/removal. However, I think its best just to use a bare kthread for the purpose of this. Best regards, Maxim Levitsky -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
