• State Resolved
  • Locked Locked
  • Replies 3 replies
  • Subscribers 31 subscribers
  • Views 511 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.

RTOS: NDK recv() - task scheduling

Daniel Vamos
Genius 3950 points

Tool/software: TI-RTOS

Hello,

I have an producer - consumer desing pattern using Mailbox. The Producer (Prio 2.) Mailbox_post(hndl, BIOS_WAIT_FOREVER) messages to the Consumer (prio 6.) task where an MQTT Client task is implemented to send mqtt messages to the broker.

On the producer side I have a for loop without any Task_sleep() calls. When I publish an MQTT message with QOS0 (when only a socket send() is called ), the Producer task is blocked as long as the Consumer send the message, everything works as expected, the Consumer has a higher priority, all is good.

However when I am trying to send a QOS1 message when the send() is followed by recv() to get the PUBACK, the Task scheduler doesn't block the Consumer task, and the Producer iterating to the next loop cycle before getting the PUBACK for its previous transfer.

Q1: What is the reason behid? Can you explaing why is it happening?

Q2: How can I make the Consumer task to wait for recv() to complete and not let the Producer task to resume?

Thank you very much

  • 0
    TI__Intellectual 1390 points
    Hi Daniel,

    Let me see if I understand the situation with your QOS1 message fully. On the Producer side you have a loop with a send() followed by a recv() inside. On the Consumer side you have a recv() call followed by a send() call.
    You do not see the Consumer block at its call to recv() - is that right? Have you checked the return of the Consumer's recv() call?
    Similarly, your Producer restarts the loop. Can you tell me what the Producer returns from its recv() call?

    I would expect the Producer, with its higher priority to send() then recv() and block before the Consumer wakes up. I would then expect the Consumer to call recv() and return the data previously sent(). All the while the Producer should be waiting at its recv() call.

    Is there a timer set forcing your Producer thread to resume execution instead of blocking indefinitely at its recv call? And is it possible that it did in fact receive something, but not what you intended?

    Best,
    Brandon
  • 0 in reply to Brandon_Green
    TI__Guru* 96960 points

    Hi Daniel,

    Did this get resolved?

    Todd

    [Updated 3/5: Marking as TI Thinks Resolved. We get in trouble if a posts sits around too long with no activity. If it's not resolved, just post a response and it opens back up]

  • 0 in reply to ToddMullanix
    Genius 3950 points
    Hello Tod,

    Lets pause this for a while, because I had to focus on other project. Thank you for your help.