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.

question about system API in DVRRDK_03.

Hi friends,
Q1. Is there any queue/dequeue or thread-save mechanism inside "System_linkControl" function?
Q2. System_linkControl is used to command and parameter delivery, not for immediate infom. Right?
  • I am sorry I dont understand the question. System_linkControl is used to send control commands to different links in DVR RDK. System_linkControl can be invoked with either waitAck set to TRUE or FALSE. If waitAck is set to TRUE it will block until the target link  responds. If waitAck is set to FALSE it will send the cmd and return immediately. If target link is not on the same core , System_linkControl will use MessageQ to send Message to remote core.

    What does immediate infom" mean ?

    What does "Is there any queue/dequeue or thread-save mechanism inside "System_linkControl" function" mean. 

       - You can refer the code of System_linkControl in /dvr_rdk/mcfw/src_linux/links/system/system_linkApi.c and understand the implementation.

  • Hi Badri,
       Thanks for your reply.

    What does immediate infom" mean ?
    - I'm clarify the usage of these function Notify_sendEvent() and System_linkControl().
    Once we got something done, we need to inform other cores right away. did you know which is better?

    What does "Is there any queue/dequeue or thread-save mechanism inside "System_linkControl" function" mean
    - For some reason, we may call System_linkControl busily. I'm not sure if this function processing will queue data and then dequeue.
    if yes, that means I can't use it for real time inform. Right?

  • As I mentioned previously System_linkControl uses MessageQ_put so you are comparing MessageQ_put with Notify_sendEvent.

    Notify_sendEvent will be faster than MessageQ_put but the latency of MessageQ_Put is itself less than 1ms so can you explain what is the latency you want to achieve when you say "right away". Have you measured any problems with System_linkControl.

    The callback on the remote core for Notify_sendEvent happens from ISR context on M3s and DSP so you have will have to anyway do something like Semaphore_post in the Notify callback and do any actual processing from a thread that is blocked on this semaphore. This is the same thing that is done in MessageQ_put so you may end up implementing all this functionality again. 

     For some reason, we may call System_linkControl busily. I'm not sure if this function processing will queue data and then dequeue.

      - If you invoke Notify_sendEvent busily it will overwhelm the remote core with interrupts and should be avoided. You need to have some flow control mechanism and should avoid sending interrupts to the remote core in a busy loop. It is better to use System_linkControl with waitAck = TRUE which ensure previous msg has been processed before next msg is sent.