On Sun, 2 May 2004, David Brownell wrote:
BTW here's a code fragment showing roughly the tree-locking algorithm I described at one point. If everyone uses this for things that can change tree topology, they'll get locks from root to affected-subtree ... in parallel, not colliding.
That looks good and might come in handy if khubd ever becomes multi-threaded. Until then it may not be needed, since khubd is the only thing that changes the tree topology.
Actually, PM suspend/resume has always come in from different threads ... and that'll be even more true given the ability for N user-mode tasks to request that.
And then there's also the HCD modprobe/rmmod case, which also bypasses khubd ...
(Saying that this algorithm locks a subtree isn't quite right, however. It locks the _top_ of a subtree but nothing below that.)
True, but that's sufficient for the rest ... assuming anything needs to lock the child nodes actually does so. (Locking might wait for an "old" task to finish ... keeping things serialized.)
- Dave
-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE. http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
