On Wed, Jul 03, 2002, David Brownell <[EMAIL PROTECTED]> wrote: > Johannes Erdfelt wrote: > > On Tue, Jul 02, 2002, David Brownell <[EMAIL PROTECTED]> wrote: > > > >>>While I agree some of the locking can be made simpler, it can't be > >>>reduced to 1 lock. > >> > >>Could you elaborate? ... > >> > >>I think that if you treat "one spinlock per HC" as a > >>technical goal, you'll find it's very possible. > > > > > > Take a look at the discussions a year (or so?) ago about the recursive > > spinlocks and the then later with the switch to using the complete list. > > > > The short of it: We need to grab usb_list_lock to find which URB > > finished, which means we hold a lock while complete() is called, and the > > URB completion routine can submit a new URB = deadlock. > > Of course, if you took a different strategy that wasn't > focussed on an URB list (like both UHCIs do), that issue > needn't come up. For example, scanning active QHs for TDs > that have completed (successfully or with errors), you know > the urb associated with each TD.
1) Not all transfers have QH's (Interrupt, Isochronous) 2) When we submit a new URB, we have to add that new QH to the list The problem here is no matter which piece of identifying information we use, we need to put it into a list and *that's* the problem. > During completion callbacks there are some invariants you > can rely on, like that URB not changing (not that it should > matter, all its TDs finished!) and that no URB could queue > in front of the TDs you already scanned. But that requires dropping the lock and that means *anything* can happen to the list. If you save the position you're currently on and acquire the lock and continue after the callback, you may find the URB you're working on disappeared already, either because of the callback or another CPU. Take a look at uhci_interrupt in usb-uhci.c for their processing loop and tell me that's something you would prefer over having 2 locks :) > > However, that doesn't cover all of the locks and I think it can be made > > simpler, but I was aiming for correctness first before sitting down and > > thinking hard about all of the locking issues with reducing the number > > of locks. > > Correctness first is indeed the way to go, but FWIW I've usually > found it's a _lot_ easer to show correctness when there are fewer > locks involved. While I would agree with that as a general rule, it wasn't this case. Anyway, I think we can reduce the locks, but I know we can't reduce it to 1 with the current URB semantics. JE ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek No, I will not fix your computer. http://thinkgeek.com/sf _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
