Michael Blizek wrote:
Hi!
Hi Michael and thank you for your reply.
On 14:35 Thu 18 Dec , luca ellero wrote:
I all,
I was reading "Unreliable Guide To Locking" by Rusty Russell:
http://www.kernel.org/pub/linux/kernel/people/rusty/kernel-locking/index.html
but the table (named Cheat Sheet For Locking) is quite confusing me:
http://www.kernel.org/pub/linux/kernel/people/rusty/kernel-locking/c214.html#MINIMUM-LOCK-REQIREMENTS
maybe it is this really _cheating_ and _unreliable_ :-(
So I want to ask you a two questions:
1. following the table it seems that, if there is a critical section
only in one place in user context, no locking is needed (if you cross
"User Context A" with "User Context A" you get "None").
You need locking *only* if there may be more than one cpu/threads, which
try to execute the critical section at the same time.
But as far as I
know, if you have critical section in a "read" syscall for example, you
must use some locking because two user processes can read the same
device at the same time.
If 2 user-space processes try to read at the same time, you have to keep
critical sections/locking in mind. If they cannot (open for the second process
fails?), you do not have to lock these operations.
Ok
BTW: Do *not* use semaphores any more, except if you need/use the counting
mechanism. Use mutexes instead (see Documentation/mutex-design.txt)
thank you for the suggestion
2. Why spin_lock_irqsave is used only between "IRQ Handler A" and "IRQ
Handler B"? In all other situation spin_lock_irq is used instead. As far
as I know you can use this function (spin_lock_irq) only if you are
absolutely sure interrupts are not already disabled. So my question is
how can we be absolutely sure in all this situation that interrupts are
not already disabled.
There are 3 different ways you can handle interrupts when locking spinlocks:
spin_lock: interrupts have to be *disabled* when calling this function
Here I don't agree completely. Think about two timers trying to access
the same variable, I think spin_lock is sufficient without disabling
interrupts (in that situation the table is clear)
spin_lock_irq: interrupts have to be *enabled* when calling this function and
are disabled afterwards - After spin_unlock_irq, they are enabled. This is the
case even if they were disabled before, which is probably not what you want.
spin_lock_irqsave: may be called with interrupts enabled and disabled - The
interrupt state is stored in a local "iflags" variable and is restored during
spin_unlock_irqrestore. Use this, if you are not sure about the interrupt
state.
-Michi
That's exactly what I mean, what is not clear for me is:
how can you be sure interrupts are not already disabled for whatever reason?
In other words, why the table doesn't use spin_lock_irqsave instead of
spin_lock_irq?
Reading the table it seems that, for example, between "User Context A"
and "IRQ Handler A" using spin_lock_irq is sufficient. But how can you
be absolutely sure interrupts are enabled during execution of "User
Context A"? Couldn't they be already disabled for other reasons?
regards
Luca
--
To unsubscribe from this list: send an email with
"unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx
Please read the FAQ at http://kernelnewbies.org/FAQ
