Hi all,
I use sigaction() to install a handler for SIGALRM, which is triggered
periodically by a timer created using setitimer(ITIMER_REAL). The handler
modifies the same data that my program (that registered the signal handler)
modifies. So I need to lock one against the other. (The program has not
executed clone(), nor is it using any threading libraries.)
My questions are:
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?)
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?)
I am asking so I know how simple/complex the locking between the two has to
be... - I suspect that it is guaranteed that only one executes at any one
time on the system and that the normal code can never be executing while a
signal handler is executing.
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.
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
flames about using kernel headers as part of a program... Using kernel
headers/code has a big advantage IMO, in that it gives you efficient, while
at the same time multi arch code, but lets not get into this flame war now).
Thanks in advance.
Best regards,
Anton
-- Anton Altaparmakov <aia21 at cam.ac.uk> (replace at with @) Linux NTFS Maintainer / WWW: http://sourceforge.net/projects/linux-ntfs/ ICQ: 8561279 / WWW: http://www-stu.christs.cam.ac.uk/~aia21/- 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/
This archive was generated by hypermail 2b29 : Sun Apr 15 2001 - 21:00:11 EST