Re: [PATCH 04/13] IR: fix locking in ir_raw_event_work

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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


[Index of Archives]     [Linux Media Devel]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Linux Wireless Networking]     [Linux Omap]

  Powered by Linux