Alan Stern wrote:
Lastly, why does a thread need to take the lock twice? Quite simply, it
needs to lock two devices. ...
Here are a couple of examples of times when a driver needs to lock two devices (always in top-down order!):
Locking two devices shouldn't necessarily involve taking any given lock twice, particularly with top-down locking policies in place everywhere. Top-down means that while you're holding a node's lock, nobody else can ever get a new lock on (that node or) one of its descendants. That's a useful invariant; it allows concurrency without needing readlocks.
I chose to use an rwsem because it was a good, albeit not perfect, match to the design requirements. If anyone can suggest a superior alternative, I won't hesitate to change the implementation. All the code is localized (not by accident!) in a handful of functions: usb_lock_device(), usb_lock_all_devices(), etc., making such a change very easy to write.
When I get a moment to re-test the CONFIG_USB_SUSPEND patch, along with its locktree() primitive, I'll repost that patch against Linus' BK tree. Deltas from the 2.6.7 patch there are for the usb_new_device() reorganization, and some smarter handling of drivers without suspend/resume support.
Then I'll have to see if those locking changes in Greg's tree break anything. I've not really made time to look at those yet; it needs some real thought. This seems like a case where cross-pollination is inevitable ... :)
- Dave
-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 - digital self defense, top technical experts, no vendor pitches, unmatched networking opportunities. Visit www.blackhat.com
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
