Il 13/08/2013 16:54, Jan Kiszka ha scritto: >> > Using an AioContext lock for timers is somewhat complicated for lock >> > ordering, because context A could try to modify a timer from context B, >> > at the same time when context B is modifying a timer from context A. >> > This would cause a deadlock. > That's like MMIO access on device A triggers MMIO access on B and vice > versa - why should we need this, so why should we support this? I think > the typical case is that timers (and their lists) and data structures > they access have a fairly close relation, thus can reuse the same lock.
Yes, that's true. Still it would have to be documented, and using too-coarse locks risks having many BQLs, which multiplies the complexity (fine-grained locking at least keeps critical sections small and limits the amount of nested locking). I like Stefan's patches to make the timer list thread-safe, especially if we can optimize it (with RCU?) to make the read side lockless. Paolo
