On Fri, 9 Jul 2004, David Brownell wrote:
> 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.
Sorry, terminology mixup. By "top-down order" I didn't mean that drivers
always start by locking the root device, then one of its children, and so
on. I meant that whenever two devices must be locked, the parent is
locked first and the child is locked second.
There are two obvious ways to avoid the need for multiple read-locking in
a single thread:
Acquire the readlock when locking the first device, but not
when locking other devices. Release the readlock when the
last device is unlocked. This complicates things by putting
the burden on the driver of keeping track of which sort of
lock is needed. usb_disconnect() would have to be changed,
because it uses exactly the same code to recursively lock
each device below a hub being disconnected.
Forget about locking individual devices and use a single
global USB device lock. This would solve everything, at the
expense of disallowing simultaneous processing of events on
multiple devices or tree traversals. Given that such things
happen relatively infrequently, maybe that's acceptable.
I didn't use either of these approaches because I wanted to stick as
closely as possible to the current setup.
> 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.
Will you adopt the naming scheme for local variables in hub.c that I
started (nudge, nudge)?
> 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 ... :)
I didn't mention it before, but your locktree() routine is another place
that benefits from the ability to take multiple readlocks.
Alan Stern
-------------------------------------------------------
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
