Messages in this thread | | | From | Felipe Balbi <> | Subject | Re: [PATCH 2/5] usb: gadget: f_midi: added spinlock on transmit function | Date | Fri, 04 Mar 2016 09:20:10 +0200 |
| |
Hi,
"Felipe F. Tonello" <eu@felipetonello.com> writes: > [ text/plain ] > Since f_midi_transmit is called by both ALSA and USB frameworks, it can > potentially cause a race condition between both calls. This is bad because the > way f_midi_transmit is implemented can't handle concurrent calls. This is due > to the fact that the usb request fifo looks for the next element and only if > it has data to process it enqueues the request, otherwise re-uses it. If both > (ALSA and USB) frameworks calls this function at the same time, the > kfifo_seek() will return the same usb_request, which will cause a race > condition. > > To solve this problem a syncronization mechanism is necessary. In this case it > is used a spinlock since f_midi_transmit is also called by usb_request->complete > callback in interrupt context. > > On benchmarks realized by me, spinlocks were more efficient then scheduling > the f_midi_transmit tasklet in process context and using a mutex to > synchronize. Also it performs better then previous implementation that > allocated a usb_request for every new transmit made.
behaves better in what way ? Also, previous implementation would not suffer from this concurrency problem, right ?
-- balbi [unhandled content-type:application/pgp-signature]
| |