VxWorks signals

Question

I have a question regarding previous question asked in VxWorks forum. My goal is when the high priority function generates a signal the low priority function will handle it immidiately(the high priority function must be preempted)

The code is:

sig_hdr () { ... }
task_low_priority() {
    ...
    // Install signal handler for SIGUSR1
    signal(SIGUSR1, sig_hdr);

    ...
}

task_high_priority() {
    ...
    kill(pid, SIGUSR1); //pid is the ID of task_low_priority
    ...
} 

After the line: signal(SIGUSR1, sig_hdr); i added taskDelay(0). I wanted to block the high priority task so the low priority task can gain the CPU in order to execute the signal handler but it does not happen unless i do taskDelay(1).

Can any one explain why it does not work with taskDelay(0)?

Answer 1

Indeed, taskDelay(0) will not let lower priority tasks run because of the following:

1. high priority task is executing
2. high priority task issues taskDelay(0)
3. Scheduler is invoked and it scans for the next task to run, it will select the highest priority task that is "ready"
4. The task that issued the taskDelay(0) is ready because the delay has expired (i.e. 0 ticks have elapsed)
5. So the high priority task is rescheduled immediately, in this case taskDelay(0) is effectively a waste of CPU cycles.

Now in the case where you issue taskDelay(1) the same steps are followed, but the difference is that the high priority task isn't in the ready state because one tick has not elapsed, so a lower priority task that is ready can have 1 tick of CPU time then it will be preempted by the high priority task.

Now there are some poorly designed systems out there that do things like:

taskLock();
...
taskDelay(0);
...
taskUnlock();

With the intention of having a low priority task hog the CPU until some point where it then allows a high priority task to take over by issuing a taskDelay(0). However if you play games like this then you should reconsider your design.

Also in your case I would consider a more robust system, rather than doing a taskDelay() to allow a low priority task to process an event, you should send a message to a low priority task and have that low priority task to process the message queue. While your high priority task blocks on a semaphore that is given by your event handler or some thing similar. In this situation you are hoping to force a ping pong between two different tasks to get a job done, but if you add a queue that will act as a buffer, so as long as your system is schedulable (i.e. there is enough time to respond to all events, queue them up and fully process them) then it will work.

---

Update

I assume your system is supposed to be something like this:

1. Event occurs (interrupt driven?).
2. High priority task runs to gather data.
3. Data is processed by low priority task.

If this is the case the pattern you want to follow is actually quite simple, and in fact could be accomplished with just 1 task:

Interrupt handler gathers data, and sends a message (msgQSend()) to task. Task is pending on the message queue with msgQReceive.

But it might help if I knew more about your system (what are you really trying to do) and also why you are using posix calls rather than native vxworks calls.

---

If you are new to real time systems, you should learn about Rate monotonic analysis, there is a very brief summary on wikipedia:

http://en.wikipedia.org/wiki/Rate-monotonic_scheduling

Also note that in VxWorks a "high priority" is 0, and "low priority" is 255, the actual numbers are inversely related to their meaning :D