* Michel Lespinasse <wal...@google.com> wrote:
> That said, I am very scared of using rwlock_t here, and I would much
> prefer we choose a fair lock (either spinlock or a new rwlock
> implementation which guarantees not to starve any locker thread)
Given how few users rwlock_t has today we could attempt to make it
reader-writer fair, as long as the usecase of a hardirq or softirq
context always getting nested read access on the same CPU is preserved.
(but that can be done - if nothing else then with an explicit context
check.)
Thanks,
Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
