Hi Michi, On Sat, Oct 8, 2011 at 11:29 PM, Michael Blizek <michi1@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx> wrote: > Hi! > > On 00:24 Sun 09 Oct , Parmenides wrote: >> 2011/10/8 Michael Blizek <michi1@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx>: >> > Hi! >> > >> > There are 2 different kind of locks: Those which can be preempted (mutex and >> > semaphores) and those which cannot (spinlocks). Spinlocks do busy waiting >> > until the lock is released. On single cpu systems, the are optimised into >> > enable/disable preemption. Spinlocks have to be used if the data it protects >> > is partly accessed in code paths which have preemption disables for other >> > reasons (e.g. being interrupt handler). This is because otherwise you have a >> > problem if you cannot preempt, but need to aquire a lock which is held by a >> > "thread" which has been preempted. >> > >> >> Except for interrupt handler, is there any other code path which >> cannot be preempted but need to obtain a lock. > > AFAIK not, but I am not really sure. > >> If not, I think a >> thread holding a spinlock can disable interrupt when it is in critical >> section to resolve this problem, rather than disable preemption. > > Disabling interrupts actually disables preemption as well. Preemption is > triggered by a timer interrupt, which cannot arrive in this case. Spinlocks > can be aquired both by disabling interrupts (spin_lock_irqsave) or by > disabling preemption (spin_lock_bh). However, you cannot use spin_lock_bh if > the same spin_lock is aquired in an interrupt handler. spin_lock_bh allows > interrupt handlers to be invoked while you are still in the critical section. > If the interrupt handler is processed on the same CPU as the critical section, > you are stuck in a deadlock. Disabling interrupts DOES NOT disable preemption on an SMP machine. It only disables preemption on the core that interrupts are disabled on. > There is a "real time" patchset which reduces spin_lock usage a lot. It > replaces many interrupt handlers with code that schedules the real interrupt > as a thread. They can then be interrupted and use a normal mutex for > synchronisation. However, this increases latency and overhead for interrupts. > It depends on the situation whether this is faster or slower. People often associate real-time with "fast", when in fact real-time really means "deterministic". -- Dave Hylands Shuswap, BC, Canada http://www.davehylands.com _______________________________________________ Kernelnewbies mailing list Kernelnewbies@xxxxxxxxxxxxxxxxx http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
