Hi, "Felipe F. Tonello" <eu@xxxxxxxxxxxxxxxxx> 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
Attachment:
signature.asc
Description: PGP signature
