2007/3/28, Robert Watson <[EMAIL PROTECTED]>:
Pretty much. We disable interrupts for the following reason: as spin mutexes may be acquired in fast interrupt handlers, they may be running on the stack of an existing thread, which may also hold locks. As such, we can't allow the fast handler to acquire any locks that are either already held by the thread, or that might violate the lock order. By restricting fast interrupt handlers to holding only spin locks, and by making spin locks disable interrupts, we prevent that deadlock scenario.
Really, avoid lock ordering violation is one of the motivations that don't allow usage of sleepable locks in fast handlers. We disable interrupts for spin-locks mainly in order to avoid to be preempted by an interrupt thread (or, however, an higher priority thread) that can contest on the spin-lock we are holding and so can cause a deadlock since we will never have a chance to be executed again (there will always be an attempt to execute first the higher priority thread that cannot start again). You can make this concept more general if you mind what you first stated -- that spinning should not be longer than rr time quantum. If you get preempted by another thread this won't certainly happen however. For this reason, you are not allowed to perform any sort of sleeping (as bounded or unbounded) while holding a spin-lock. Attilio -- Peace can only be achieved by understanding - A. Einstein _______________________________________________ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
