Windows: Fix deadlock in backend when submitting transfers.
commit1ed09c7b2a5fc27c3cfea21740584879781bff67
authorToby Gray <toby.gray@realvnc.com>
Thu, 3 May 2012 10:25:11 +0000 (3 11:25 +0100)
committerPete Batard <pete@akeo.ie>
Thu, 3 May 2012 20:54:07 +0000 (3 21:54 +0100)
tree621da73f9bdf7c4f2df10583ab109c14665d8fb4
parent939a4782b28c36dfddb68585c4b027a4d5494a5b
Windows: Fix deadlock in backend when submitting transfers.

Without this change the Windows backend needed to call usbi_fd_notification()
from within the backend's submit_transfer. This can cause deadlock when
attempting to lock the event lock if another thread was processing events on
the just-submitted transfer.

The deadlock comes about as the thread calling libusb_submit_transfer acquires
the transfer mutex before trying to acquire the event lock; this is the other
order of lock acquisition from an event thread handling activity on the just
submitted transfer. This could lead to one of two deadlocks:

1) If the transfer completes while usbi_fd_notification() is waiting for
the event lock and the callback attempts to resubmit the transfer.

2) If the transfer timeout is hit while usbi_fd_notification() is waiting
for the event lock then the attempt to cancel the transfer will deadlock.

This patch fixes both of these deadlocks by having libusb_submit_transfer()
only call usbi_fd_notification() after having released the transfer mutex.
libusb/io.c
libusb/libusbi.h
libusb/os/windows_usb.c
libusb/version.h