Task_Yield in BIOS6

SNBANIK said:

1. Does Task_Yield result in the currently active task temporarily yielding the CPU? In other words, does the task come back and resume what it was doing?

2. My need is for the task to abandon what it was doing and go back to Pend call. Will Task_Yield achieve that?

Task_yield() does not cause a task to block.  It causes it to change states from "running" to "ready".  This means that if there is another thread of the same priority that was already in a "ready" state then that thread will run.  If only lower priority threads are ready then the current task will continue to run (i.e. it will immediately switch back from "ready" to "running" since it will be the highest priority "ready" task in the system).

SNBANIK said:

3. Can a SWI ot HWI execute Task_Yield to force the active task to achieve my need above (item 2) ?

Yes, though you must use the dispatcher to call Task_yield from a HWI.

SNBANIK said:

4. Does this work in the case where there is only one task in the system?

With only one task in the system it won't have any effect, i.e. it will cause the task to go from running to ready to running again.

Thanks Brad for your reply. It is clear Task_Yield is not going to serve my need.

Is there a way in BIOS6 that meets my need as in item 2 of my original post. 

Here is the scenario: processor c6472. Core 0 runs the BossTask that handles interaction with external world (an external host processor) and controls rest of the cores (by means of IPC messages). Other cores run tasks that execute various algorithms. If the host processor wants the DSP to stop previous mode and switch to a different mode, all the tasks that run various algorithm need to stop immediately what they were executing and go back to wait for command from BossTask (pend on message get). 

SNBANIK

Did you ever figure anything out?  I was trying to think along the lines of having your messaging thread as a high priority such that it would immediately pre-empt your processing when a message came in.  That task could then delete your existing processing task and create a new one of whatever type was specified by the message.  I imagine there are some nitty gritty points to this.  The most obvious thing would be that your dynamically created task would not be "allowed" to dynamically allocate its own memory. Otherwise when you delete the task it will never be freed.

Maybe someone else will have other ideas.  I've not actually tried anything like this before so perhaps I've missed an important detail, but since nobody else has replied I thought I'd throw out the one idea that I had.

Hi Brad,

 Thanks for your reply. I had hoped too someone would have ideas for us to handle this situation. What you have described is something we had thought too but wasn't going to be our first choice. We are looking for a solution that wouldn't need to delete a task and then recreate it. But if nothing else works, that may be the way out.

The task in our case would sleep waiting for a message to arrive. If somehow I can make the task to stop what it was doing and go back to sleep for next message, that would be best.

Somnath Banik

There's no way for the task to just stop what it's doing aside from deleting it.  The alternative would be to build a checking mechanism into the task itself.  However, that would incur latency because for example it might process a frame of data and then check to see if a new message arrived.  The latency would be dependent upon how long it goes between checking to see if a new message arrived.  If you can check for messages quite often this would be a simpler approach.