Task in Vxworks

how can a vxworks task let all other lesser priority tasks run for a single multitasking cycle?

A higher priority task will always run, if it is ready, and if you haven't called taskLock() or intLock() etc, so you dont need to taskDelay() to let higher priority tasks run.

taskDelay(0) will place the current task at the back of the ready queue for that priority level. If it is the only task at that priority, it will be immediately rescheduled regardless of the presence of lower priority tasks

taskDelay(n>0) will place the current task at the back of the ready queue, for that priority, and it will not be rescheduled for n ticks. This will allow any ready tasks of lower priority to run.

The parameter to taskDelay() is ticks, not ms. The length of this can be determined based on the system clk rate (which you set by sysClkRateSet(), and read by sysClkRateGet() ). 1 tick might equal 1ms, but only if the system clk rate is 1000. Which it probably wont be. The default rate is 60, which gives a 16ms tick, but this is normally overridden either statically in the kernel config, or dynamically by calling sysClkRateSet()

NOTE: This system clock is not the same as the CPU freq.

vxWorks task blocks shell command input

The VxWorks scheduler is priority based. Tasks are executed on a first come first serve basis (round-robin is disabled by default).

So if your task runs continuously it blocks all tasks of lower priority (higher number = lower priority in VxWorks) since the scheduler chooses the higher priority tasks to run first.

To deal with that you mainly have the following options:

• Add a taskDelay(1); to your processing loop. This blocks your thread for one system tick and enables threads with lower priority (like tShell in your case) to run.
• Spawn your thread with lower priority than the shell (e.g. 110) to force it running in the background.

Depending on the scenario I recommend the latter since depending on your task adding a taskDelay(1); may slow down processing significantly (and increasing the system tick using tickSet(..) to values above 1000 increases interrupt load dramatically). If you decrease the priority on the other hand your task will run except a higher priority task (e.g. the shell) is ready to run. In that case your task will be interrupted until the higher priority task has finished processing (e.g. your termination command is executed).

Setting name of initial task in a vxworks RTP

One option is to just spawn a new, named, task immediately on entry to the RTP, and perform the work in this task.

The Initial task should then be exited using taskExit() to ensure that the RTP is not removed.

How does vxWorks deal with two tasks at the same priority?

The task that will run first is the task that is spawned first as realized by the VxWorks scheduler task. VxWorks uses priority-based scheduling by default. So in your case, since T1 and T2 have the same priority, whichever one gets the CPU first will continue to run indefinitely until it is explicitly blocked (using taskSuspend or taskDelay), at which time the other READY task will execute until it is blocked, and so on. This ought to be controlled by semaphores or mutexes (mutices?)

The main problem with priority-based scheduling is illuminated by this exact problem. How do we determine how long to let these tasks run? The fact that they have the same priority complicates things. Another concern is that VxWorks tasks that have high priority (lower number means higher priority) can preempt your application which you must be prepared for in your code. These problems can be solved by using round-robin scheduling. The additional problems posed by round-robin scheduling and the solutions are all described here.

---

Related Topics