Messages in this thread | | | Date | Sat, 28 Sep 2002 17:50:19 -0700 | From | William Lee Irwin III <> | Subject | Re: Sleeping function called from illegal context... |
| |
On Sat, 2002-09-28 at 13:24, John Levon wrote: >> NMI interrupt handler cannot block so it trylocks against a spinlock >> instead. Buffer processing code needs to block against concurrent NMI >> interrupts so takes the spinlock for them. All actual blocks on the >> spinlock are beneath a down() on another semaphore, so a sleep whilst >> holding the spinlock won't actually cause deadlock.
On Sat, Sep 28, 2002 at 02:27:44PM -0400, Robert Love wrote: > If all accesses to the spinlock are taken under a semaphore, then the > spinlock is not needed (i.e. the down'ed semaphore provides the same > protection), or am I missing something? > If this is not the case - e.g. there are other accesses to these locks - > then you cannot sleep, no? > I really can think of no case in which it is safe to sleep while holding > a spinlock or otherwise atomic. If it is, then the atomicity is not > needed, sort of by definition.
Actually, though he may be using a spinlock_t, when used this way, it is not a spinlock, but rather a semaphore-like construct like PG_locked. Spinlocks include blocking via busywait semantics, which this usage does not have. It just happens to use the same data type. There are other interesting abuses of spinlock-like constructs in "advanced" locks, for instance, in non-sleeping handoff-scheduled queueing locks (e.g. MCS spinlocks and rwlocks) it's a common idiom for one waiter to set a "blocked" bit or lock word and then spin on it until another waiter and/or cpu manipulating the lock clears it.
Bill - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |