On Wed, 9 Mar 2005, Patrick Mochel wrote: > On Wed, 9 Mar 2005, Alan Stern wrote: > > > This is a complex scheme. But it has to be; there's no way for > > device_attach, driver_attach, and driver_detach to iterate through the > > lists reliably if the lists are subject to concurrent change. If the > > lists are busy, these routines have only two choices. They can either > > queue a request for an update and return immediately, or else wait until > > the lists aren't busy -- which is exactly what the current rwsem scheme > > does. > > > > Comments? > > Yes. First of all, this is a totally different topic than suspend/resume. You're right. The thread starting out discussing locking and mutual exclusion for suspend/resume and wandered on from there. Where would be a better place to discuss locking and the driver-model core? > Secondly, discussion about locking issues and fixes are *much* harder to > do with prose, and *much* easier to express with code. If you get the code > right, it speaks for itself. That's subjective. I personally find prose *much* easier to understand than code up until the later stages of development, for most purposes. For expressing particular algorithms I agree that code (or pseudo-code) is better. > Finally, there is an elegant solution to this problem that I'm trying to > update the patches for. Basically, it extends struct list_head to have a > reference count, where it can only be removed when it hits 0. A spinlock > is held while grabbing and incrementing the reference for each node (and > decrementing the count for the previous held node). The lock is dropped > and a callback called, which can then sleep and modify the list that the > node sits on. Dmitry's suggestion seems simpler and easier. > Updated patch coming soon. I'll look for it. Alan Stern
