Strange results in multiprocess signal handling program

Question

I have this multiprocess program which consists of 9 processes. One is the main process which spawns 3 signal generating processes and 4 signal handling processes. One is the monitoring process. Now I have used two signals SIGUSR1 and SIGUSR2. Each of the handlers can handle either SIGUSR1 or SIGUSR2. Whenever, they receive a signal they increase the count of the signals SIGUSR1 and SIGUSR2 in the shared memory by 1. The monitoring process also receives the signals since the signals are sent to the process group. It can handle both the signals and increases it's local signal count by 1.Whenever it reaches 10, it prints out the value of the count of SIGUSR1 and SIGUSR2 in the shared memory.

I have this options in the main program, it can either run for 30 seconds and terminate the program, in which case I do sleep(30) and then terminate the program. In the second case it busy waits in a while loop, counting the total count of SIGUSR1 and SIGUSR2 in the shared memory. When it reaches 100000, it terminates the program.

Here are my outputs for the two version

For the 100000 second version

For the 100000 signal version output

  Initializing the shared memory
   End of initializing the shared memory
   Registering the signal handlers
   End of registering the signal handlers
   Registering the monitoring process
   Monitor's pid is 6635
   End of registering the monitoring process
   Registering the signal generators
   Interval SIGUSR1 = 5.79953e-05
   Interval SIGUSR2 = 8.69632e-05
   Count SIGUSR1 = 10
   Count SIGUSR2 = 10
   Count SSIGUSR1 = 5
   Count SSIGUSR2 = 5

   Interval SIGUSR1 = 7.64132e-05
   Interval SIGUSR2 = 5.72999e-05
   Count SIGUSR1 = 16
   Count SIGUSR2 = 24
   Count SSIGUSR1 = 8
   Count SSIGUSR2 = 12

For the 30 second version

Initializing the shared memory

 End of initializing the shared memory
   Registering the signal handlers
   End of registering the signal handlers
   Registering the monitoring process
   Monitor's pid is 6719
   End of registering the monitoring process
   Registering the signal generators
   Inside option 1
   Interval SIGUSR1 = 0.000246763
   Interval SIGUSR2 = 0.000222743
   Count SIGUSR1 = 93
   Count SIGUSR2 = 222
   Count SSIGUSR1 = 92
   Count SSIGUSR2 = 111

   Interval SIGUSR1 = 0.000664711
   Interval SIGUSR2 = 0.000390577
   Count SIGUSR1 = 102
   Count SIGUSR2 = 234
   Count SSIGUSR1 = 97
   Count SSIGUSR2 = 117

Why are the results so lagging in the second case. I mean when the monitor first prints the output, the count of SIGUSR1 and SIGUSR2 as recorded by the handling threads had already reached 93 and 222. Also the signal is sent to the process group. So each signal is handled by two handlers and one monitor. It is only two in the case of handlers because out of four handers, two handle SIGUSR1 and ignore the other signal and vice versa.

So you can see whats wrong when I do sleep(30) and see the results. Any insights. I have been trying to debug this for days but not successful yet.

score 1 · Answer 1 · answered Apr 19 '16 at 11:27

Signals might be merged upon receival (signals work as an hardware interrupt controller). Example:

Process 2 sends signal SIGUSR1 to Process 10, which is currently not active.

Kernel stores Process 10 has a pending SIGUSR1

Process 3 sends signal SIGUSR1 to Process 10, which is currently not active.

Kernel stores Process 10 has a pending SIGUSR1 (which it already had)

Process 10 is scheduled in, it sees that SIGUSR1 is pending, remove pending and start signal handling

Result, Process 10 only saw one SIGUSR1.

When you now add that flood the system with signals, the order the signals are schedules can cause some signals to appear more often than others.

Conclusion: Signals are not meant as a communication path, but to nudge processes. For communication you use semaphores, pipes, files etc, and signals to wake up / tell other processes that they should check for changes.

Strange results in multiprocess signal handling program

1 Answers1