Re: spinlocks and preemption

[Fawad Lateef <fawadlateef@xxxxxxxxx>]

On 11/9/05, Bahadir Balban <bilgehan.balban@xxxxxxxxx> wrote:
> Hi,
>
> I have some basic questions. Answering just yes or no should suffice
> for me. If we say there are 3 levels of execution context:
>
> 1) Process context
> 2) Bottom-Half context
> 3) Irq context
>

Yes, correct !

> Is it correct to say that;
>
> 1) An in-interrupt context cannot sleep but it can be preempted if the
> irqs are enabled. (Examples: inside a non-SA_INTERRUPT interrupt
> handler or a tasklet)
>

Yes, this is what I know too !

> Spinlocks:
> 2) No matter what context you are in, by acquiring a spinlock,
> preemption is *always* disabled, to cover for the *always possible*
> case of another process scheduling and deadlocking on the lock.
>

Yes, thats what the spin_lock code do (means disabling preemption)

> 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 got what you want to say/ask ?

> 4) Disabling of contexts for a spinlock is to protect against
> deadlocks from the current CPU, whereas the spinlock itself is to
> protect against races across CPUs. Does this also imply, the runqueue
> of a CPU would never be balanced when a context on that CPU holds a
> spinlock?
>

I can't say about this !

--
Fawad Lateef

--
Kernelnewbies: Help each other learn about the Linux kernel.
Archive:       http://mail.nl.linux.org/kernelnewbies/
FAQ:           http://kernelnewbies.org/faq/