On 11/9/05, Fawad Lateef <fawadlateef@xxxxxxxxx> wrote: > > 3) No matter what context you're in, *if, and only if* your spinlock > > is shared with BH and/or Irq contexts, you disable them on the current > > CPU, for they may interrupt yours, and deadlock on your spinlock. > > > > I won't able to get what you want to say/ask ? Thanks for the reply. I tried to make it a summary, sorry if its unclear. I actually meant, the *resource* is shared with BH and/or IRQ contexts. 3) So in verbose words, no matter whether you're in process, interrupt or bottom half context, iff your resource is shared with a BH and/or IRQ context, you disable that context on the current CPU when acquiring the spinlock. Because they may interrupt yours, attempt to lock your resource and deadlock. > > 4) Does this also imply, the runqueue > > of a CPU would never be balanced when a context on that CPU holds a > > spinlock? > > Do you mean that tasks in the runqueue of the CPUs will become > un-balanced when a CPU is waiting on/for the spin_lock then you are > right ! > > -- > Fawad Lateef To clarify this; for (4) I meant a CPU with a context that holds a spinlock would never be involved in a runqueue balancing with other CPUs, to avoid possible deadlocks. To open this, a scenario I made up: Process (A) holds a spinlock on CPU A, to protect against a BH (B) on CPU B. Because the BH (B) is on CPU B, Process (A) hasn't disabled bottom halves when acquiring the lock, as there's no point doing so. Furthermore while holding the spinlock, imagine a runqueue balancing happens and it is migrated to CPU B. Then is there a danger that bottom half (B) takes over, attempts on the spinlock and deadlocks CPU B? Thanks, Bahadir -- Kernelnewbies: Help each other learn about the Linux kernel. Archive: http://mail.nl.linux.org/kernelnewbies/ FAQ: http://kernelnewbies.org/faq/
