> Oh! And from this thread, my understanding of the reason for the rule > of lock sequence: coarse->fine is that biglock means higher > possibility of conflict, so we try it first, then try the fine-lock. > In this way, we have a smaller window for holding fine-lock which > means the other thread can get this lock more smoothly. Right?
Yes. > NOT want to open an argument, just a question, is there any reason > for the sequence devlock->timelock? Not any particular reason, just that it makes more sense. :) Backend subsystems (timers, network, I/O handlers, ...) typically will not call anything else. So it makes sense that their locks are held inside the device locks (and inside the big lock). Also note that while the timer subsystem could call the devices, it is perfectly plausible that the devices will do for example a qemu_mod_timer from a timer callback. Thus, in some sense the timer subsystem already has to expect modifications of its state during the callback. Releasing the lock during callbacks is "just" an extension of the current behavior. Of course some changes are needed to the invariants, such as the one Avi pointed out elsewhere in the thread, but devlock->timerlock is overall more natural than the opposite. Paolo
