Linux/vxworks signals

I came across the following in a vxworks manual and was wondering why this is the case.

What types of things do signals do that make them undesirable?

In a开发者_JAVA技巧pplications, signals are most appropriate for error and exception handling, and not for a general-purpose inter-task communication.

The main issue with signals is that signal handlers are registered on a per process/memory space basis (in vxWorks, the kernel represents one memory space, and each RTP is a different memory space).

This means that regardless of the thread/task context, the same signal handler will get executed (for a given process). This can cause some problems with side-effects if your signal handler is not well behaved.

For example, if your signal uses a mutex for protect a shared resource, this could cause nasty problems, or at least, unexpected behavior

  Task A                       Task B               Signal Handler
  Take  Mutex
   ...
   Gets preempted 
                                does something
                                 ....
                                <SIGNAL ARRIVES>----->Take Mutex  (blocks)
   resumes
   ....
   Give Mutex
                                                ----->Resumes Handler

I'm not sure the example above really conveys what I'm trying to. Here are some other characteristics of signals:

• Handler not executed until the task/process is scheduled. Just because you sent the signal, doesn't mean the handler will execute right away
• No guarantee on which Task/Thread will execute the handler. Any thread/task in the process could run it (whichever thread/task executes first). VxWorks has ways around this.

Note that the above only applies to asynchronous signals sent via a kill call.

An exception will generate a synchronous signal which WILL get executed right away in the current context.