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 majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/