On Mon, Apr 09, 2001 at 12:32:02PM +0100, Anton Altaparmakov wrote:
> 1. On SMP, is it guaranteed that only one (handler vs. normal program code)
> executes at the same time? (Or is it possible, for example, that signal
> handler runs on CPU1 while the normal program code is executing on CPU2?)
It's not possible (as long as you don't use multiple threads at least)
>
> 2. Is it guaranteed that execution of the normal program code is only
> resumed when the handler "return"s? (Or is it possible, for example, that
> while the handler is running, a reschedule occurs in such a way as that
> normal program code is executed before a subsequent reschedule continues
> with the handler code?)
It's is guaranteed. A signal handler is really like a private interrupt,
not a special thread.
> If this is correct, the program (non-handler) code can assume for sure that
> it will never encounter any of the locks held as the handler will have
> finished and unlocked them before execution is returned.
Yes.
>
> This would mean 1) I can grab locks in normal program code knowing that
> they will succeed immediately and 2) the signal handler doesn't need to do
> any locking at all. Just need to check if lock is held and if it is return
> immediately as it is impossible that the lock is unlocked while we are in
> the handler or that any code executes which would necessitate the lock to
> be held. - This would mean I can use a simple spinlock and use spin_lock()
> and spin_unlock() in the normal code and just a spin_is_locked() test in
> the handler. Anyone can see anything wrong with this? (Apart from the usual
It's ok, but you don't really need to spin. A flag is enough. Also you
could use the signal blocking function (sigprocmask), but they're slightly
more expensive than just setting a flag.
-Andi
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
