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. 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. > 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. - Dave ------------------------------------------------------- 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
