It depends on the operating system. If you are talking about Linux then see "signal" in section 7 of the Linux manual:
"A signal may be generated (and thus pending) for a process as a whole
(e.g., when sent using kill(2)) or for a specific thread (e.g., certain
signals, such as SIGSEGV and SIGFPE, generated as a consequence of exe‐
cuting a specific machine-language instruction are thread directed, as
are signals targeted at a specific thread using pthread_kill(3)). A
process-directed signal may be delivered to any one of the threads that
does not currently have the signal blocked. If more than one of the
threads has the signal unblocked, then the kernel chooses an arbitrary
thread to which to deliver the signal."
Thus it also depends on your threads, if they block or not the SIGALRM signal. If you want to receive a process pending alarm with a specific thread, then only this thread should unblock the corresponding signal, and the other ones should block it. Be aware that the main thread (which corresponds to the main function in C) usually has the SIGALRM signal unmasked. This mask is inherited from the parent process if your process has been created through a fork(). By default the shell creates processes with SIGALRM enabled.
Hope it will help...
PS: All Linux threads are kernel threads with the NPTL (Native POSIX Thrad Library) since version 2.6 of the Linux kernel.
Thank you, Xavier. Your description of the process is very helpful. Maybe, I failed to mention that the question is concerned with Windows OS environment.
Sorry, didn't know it was for Windows. You should have a look to the Windows threads programming documentation. However, as Windows Threads are POSIX ones the behavior may be the same as Linux. Anyway the signal handling usually hardly depends on the OS. Maybe the following link can help you ...