• State Resolved
  • Locked Locked
  • Replies 5 replies
  • Subscribers 101 subscribers
  • Views 1644 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

Pending on Multiple Objects

rambabu surada
Intellectual 715 points

Can we have a task multiple objects like multiple mailbox_pends ?

  • 0
    Intellectual 715 points
    Correcting typos

    Can we have a task to pend on multiple objects like multiple mailbox_pends ?
  • 0 in reply to rambabu surada
    TI__Genius 12025 points

    Rambabu,

    Yes, you need to use an Event object. First create an event object. Then assign the event object to the mailbox create parameter along with a unique event ID. Use the same event object for each mailbox your create, but give each mailbox a unique event ID. Then have your task wait on the event object (Event_pend).

    When your task returns from this call, one or more mailbox objects will have a message available. Your task will need to inspect the event mask to see which mailbox has a message. The task must then call Mailbox_pend to get the message. Use a timeout of BIOS_NO_WAIT. The task should return immediately with a message. Process your message as usual. Repeat this for each bit set in the event mask.

    Handling multiple messages. When your task is working on a mailbox, you must drain all messages in the mailbox. Call Mailbox_pend in a loop until you return without a message. Do this before moving on to the next mailbox. This is needed because two or more message might be delivered into the mailbox before your task is allowed to run. However, there is only a single bit in the event mask (not a count of messages). If you left a message in the mailbox, when your task calls Event_pend again, it would not know there is a waiting message.

    Any messages delivered after your task has returned from Event_pend will generate a new bit in the event mask. Depending on the timing, these late messages may get picked up early (i.e. as the task is currently running) or on the next time around. If the message is picked up early, the mailbox will still generate a bit in the event object. This means that your task might return from Event_pend but find the mailbox empty. It just means that the message was picked up on the previous loop. This is okay, not an error condition. No message was lost.

    Look in the SYS/BIOS User Guide for more information on Events.

    ~Ramsey

  • 0 in reply to Ramsey
    Intellectual 715 points
    Thanks a lot Ramsey!
  • 0 in reply to rambabu surada
    Intellectual 715 points
    Ramsey

    Can I apply the same concepts for Queues using a semaphore for signaling between the threads?
    Are there any recommendations ?

    Much appreciated!
  • 0 in reply to rambabu surada
    TI__Genius 12025 points

    Rambabu,

    Yes, you can use the same concept with queues, and you don't need to use a semaphore. The "producer" task will add an item into a queue and then call Event_post to signal data is ready. The "consumer" task will wait by calling Event_pend. There can be many producer tasks each adding to their own queue. Just make sure each producer task uses the same event instance but a unique Event_ID. A single consumer task can use the same event instance to wait on many input sources, such as mailboxes and/or Event_ID.

    The mailbox has implicit support for the event but ultimately it just calls Event_post. The Queues do not have implicit event support, so you must call Event_post yourself right after adding something to the queue. But the end result is the same; one consumer, many producers.

    As with the mailbox, be sure to drain the queue when the consumer removes items from the queue. The same race condition exists with queues as well.

    ~Ramsey