• State Resolved
  • Locked Locked
  • Replies 2 replies
  • Subscribers 98 subscribers
  • Views 399 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Limitations of Syslink/Ipc with Multi-threaded DSP code?

Lee Holeva
Genius 4615 points
Other Parts Discussed in Thread: SYSBIOS

I've attempted to get expand my Syslink/Ipc app so that upon certain notifications from the host a new task is created on the DSP. I managed to get this to work with one new thread, but when I try to create a second task, even after deleting the previous task, I get the following assertion error from Ipc:

ti.sdo.ipc.ListMP: line 417: assertion failure: A_nullPointer: Pointer is null

ti.sysbios.gates.GateMutex: line 114: assertion failure: A_badContext: bad calling context. See GateMutex API doc for details.

xdc.runtime.Error.raise: terminating execution

If I remove the task creation code the assertion goes away. What are the current limitions imposed by Syslink and Ipc on multi-threading in the DSP? Is the Syslink/Ipc code thread safe?

Instead of having one task that receives notifications and passes messages to the host, is it possible to spread this out over multiple DSP tasks? In other words, can I have multiple instances of Ipc_attach(), one in each task? Each task would deal with its own set of notications and each would have a pair of message queues communicating with the host.

 

Lee Holeva

  • 0
    Genius 4375 points

    Lee Holeva said:

    If I remove the task creation code the assertion goes away. What are the current limitions imposed by Syslink and Ipc on multi-threading in the DSP? Is the Syslink/Ipc code thread safe?

    SysLink & IPC APIs are generally thread safe.  However, it is necessary to satisfy the calling context requirements of the APIs. For example, certain APIs cannot be called from Hwi or Swi-level threads.  It is best to refer to the SysLink/IPC documentation for information regarding these constraints.  FYI, we have a bug filed against providing more detailed calling-context related documentation with the documentation.  Until this is addressed, please let us know if you have questions regarding any specific APIs.

    Lee Holeva said:

    Instead of having one task that receives notifications and passes messages to the host, is it possible to spread this out over multiple DSP tasks?

    Yes.

    Lee Holeva said:

    In other words, can I have multiple instances of Ipc_attach(), one in each task? Each task would deal with its own set of notications and each would have a pair of message queues communicating with the host.

    Yes, this is possible.  Each Ipc_attach/detach increments/decrements a local counter so that only the first attach does the actual 'attaching' and the last detach does the actual 'detaching.'  

    Also, each Task can indeed have its own MessageQ and send notifications independently of other Tasks on the same processor.

  • 0 in reply to Shreyas Oppanthaya
    Genius 4615 points

    Shreyas Prasad said:

    Yes, this is possible.  Each Ipc_attach/detach increments/decrements a local counter so that only the first attach does the actual 'attaching' and the last detach does the actual 'detaching.'  

    Also, each Task can indeed have its own MessageQ and send notifications independently of other Tasks on the same processor.

    I put-together some code to do this, with three tasks of equal priority, but I find that only the first task gets executed.  After the first task completes BIos goes right to the idle task.  The other two tasks are blocked by a semaphore of unknown origin.  See for more details:

    http://e2e.ti.com/support/embedded/f/355/t/122672.aspx

    Lee Holeva