question on messageQ

Processor A cannot deliver the second message until it receives ack back from the first msg so this situation will not occur

if processor A/B send messages continuously to processor C, and C will feedback ack for each of A/B.

Will it halt?

No it will not halt

if not, would you mind to explain this?

one more question is in rdk3.5, each processor will allocate memory and separate it into several parts(maybe 4 or 5) and put it in Q, if there's 7 or 8 tasks and send messages to others'  processor at the same time. Will it halt or hang? if not, why?

Before sending a message from core A  to a remote core B, core A will acquire a mutex. The flow is below:

Core A

---------

   -- Acquire Mutex

       -- MessageQ_alloc  (Allow from free queue.DOnt really alloc a msg)

       -- MessageQ_put

       -- MessageQ_get -- waitForAck

       -- MessageQ_free  (Free into free queue.DOnt really free a msg)

  -- Release MUtex

-----------

 This means on coreA only _one_ outstanding msg can be present and it is not possible for multiple tasks to simultaneously send msgs.

THis is the same reason why the first case you mentioned also has no issues. Each core would be sequentially sending msgs to core C and wating for ACK.

did you mean the MUTEX protection was done only in sender or in sender/receiver both? 

Mutex protection is required only on sender. Never on the receiver.

two more question

Q1. if there's so many messages need to be sent, will it be dropped because they're buffered in sender?

Q2. if the ACK was dropped, will the system halt or hang?

Jack1234 said:

Q1. if there's so many messages need to be sent, will it be dropped because they're buffered in sender?

- Messages are never dropped. If multiple tasks simultaneously try to send msgs all will be blocked on waiting for ownership of the MsgQ mutex.

Jack1234 said:

Q2. if the ACK was dropped, will the system halt or hang?

- Ack is also never dropped.

two more question

Q1. how did you guarantee the messages/ACK will never be dropped? aren't there buffer limitation?

Q2. if process A sent msg to processor B, and B was doing the related operation. At the same time, processor C sent msg to B. Will the msg from C be lost? if not, why?

hi badri,

Q3. because force ACK was used, that mean the delivery by msgq will be paused shortly under busy delivery. right?

Jack1234 said:

Q1. how did you guarantee the messages/ACK will never be dropped? aren't there buffer limitation?

  MessageQ is a link list.It does not have any max queue length limitation.If you are able to allocate a message message you will be able to queue it for processing.Message will never be dropped.

Jack1234 said:

Q2. if process A sent msg to processor B, and B was doing the related operation. At the same time, processor C sent msg to B. Will the msg from C be lost? if not, why?

Msg C will not be lost. Messages are queued until processed. There is no possibility of dropping msgs.

Jack1234 said:

Q3. because force ACK was used, that mean the delivery by msgq will be paused shortly under busy delivery. right?

 I don't understand the question. I have already explained how waitACK works previously.

hi badri,

   Very thanks for your detail and kindly reply

two more question

Q1. when the ACK will be feedback? once the receiver got the message? or after the receiver finish the command inside messages? would you mind to tell me which file do that?

Q2. when the receiver got messages from A and B at the same time, how did the receiver feedback the ACK? first-in first out (FIFO) or else? would you mind to tell me which file describe that?

Jack1234 said:

Q1. when the ACK will be feedback? once the receiver got the message? or after the receiver finish the command inside messages? would you mind to tell me which file do that?

ACK will be sent after command processing is complete.

Jack1234 said:

Q2. when the receiver got messages from A and B at the same time, how did the receiver feedback the ACK? first-in first out (FIFO) or else? would you mind to tell me which file describe that?

ACK is sent in FIFO order.

Refer /dvr_rdk/mcfw/src_linux/links/system/system_ipc_msgq.c for MessageQ related functions

hi badri,

you're a so nice superman

by checking /dvr_rdk/mcfw/src_linux/links/system/system_ipc_msgq.c, we found following description.

does it mean there's a potential problem when we change display resolution during processing?  if not, would you mind to explain the detail?

Void *System_ipcMsgQTaskMain(Void *arg)
{

...

/* TODO: Commenting this print for release purpose. Need to enable &

* fix this failure occurring on disp resolution change
*/