does sending a signal cause task switching

Hi all,

i am porting a system, that used to manipulate memory across processes using an interrupt handler - which means that upon return from the interrupt handler the memory change would be finished. I am trying to simulate this using signals on Linux 2.6.2x.

What i would like to know is wether sending a signal (ex. kill( pid , SIGUSR1 ) ) from a process will cause the kernel to perform taskswitching and put the calling process in queue, allowing the signal handler to run if it is ready?

A simplified scenario:
We have a shared memory area attached to both processes "share".

Process1:
...
share->variable = 0;
kill( Process2_pid , SIGUSR1 )
printf("share->variable= %d\n",share->variable);
...

Process2:
SIGUSR1_handler()
{
share->variable = 1;
}

It seems that the printf allways prints a "1" . Which would mean that taskswitching occurs, and that the handler in process2 has finished when process1 returns from kill().

But is this something one can rely on Running Linux 2.6.2x ?

Regards
Paul

I do not think you cannot depend on process 1 to wait for process 2. The signal is asynchronous. Your results are dependent on an assumed timing that the signal will be received and processed before the sending process executes the next line.

To be atomic, you need to use a semaphore, for example.