On Tuesday 03 August 2004 08:47, Alan Stern wrote: > Non-data signalling on a port _is_ a good reason to lock the whole subtree > below that port, I agree. What I don't agree is that locktree() > provides the correct sort of locking for general non-data signalling. > The way I see it, locktree() is appropriate for suspend and resume, but > not for khubd or device reset.
But if it's appropriate for suspend/resume, it's appropriate for those others too -- since they are doing non-data signaling (or are prepared to do so). > Furthermore, even with suspend and resume, locktree() alone isn't enough. > For example, your suspend routine uses locktree() to lock the topmost hub > being suspended, but then it _still_ has to use ->serialize locking on > each of the devices below that hub. That's part of the serialization algorithm ... locktree() only gets the first lock. Not an issue; grabbing udev->child[i]->serialize when you already hold udev->serialize is the locking policy, used exactly the same by locktree() and everything else. > > The kind of answer I want is simple, like "everyone just > > use locktree() and it works". Special cases are negatives. > > I hope my answer was simple enough for you. More details are below. No, you started by adding special cases... :) > > Clearly there's no "need" to have a simple rule like that; > > an armload of special cases (or even just a handful) > > could work too. Likewise no need to have a cheap way > > to lock multiple devices; one _could_ just as well grab > > all the device locks for a whole subtree before starting > > some complex operation. > > You may not have noticed it, but that's not so different from what > suspend() actually does. usb_disconnect() too. In fact, you could avoid > using locktree() with suspend() if you locked the entire subtree at once. Getting all the locks at once is slower, and prevents simple cases of concurrency like one task finishing while the other is starting. Yes I did notice that ... part of why I mentioned the option, since it has negative characteristics compared to locktree(). > I agree that performance isn't an issue at this time. As for exceptions > to the locking rule -- I think suspend() and resume() _are_ exceptions and > should be treated that way. I think you _want_ them to be exceptions. It's simpler if they aren't, IMO. > Consider the other cases where I've said that locktree isn't needed: > hub_events and usb_reset_device. When a significant port event (like a > connect-change) occurs, khubd will disconnect everything below the port. > When a hub is reset, everything below that hub will be disconnected. In > short, these other cases all involve disconnecting an entire subtree. > Suspend and resume are exceptions in that they involve a subtree which > survives the operation! Yet I've demonstrated a locking policy that works the same in all those cases, without claiming that, for example, reset() is a special case "because the devices vanish". (Because in fact they don't necessarily vanish, and it might be desirable to arrange things so it doesn't look as if they did... without needing to re-whack locking again first!) - Dave ------------------------------------------------------- This SF.Net email is sponsored by OSTG. Have you noticed the changes on Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now, one more big change to announce. We are now OSTG- Open Source Technology Group. Come see the changes on the new OSTG site. www.ostg.com _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
