RTX os_evt_get behaviour

Hi guys,

Just a quick one, can anyone confirm the behaviour of os_evt_get?

I'm wishing to share a buffer between two threads of different priority. When the thread of higher priority wishes to use the buffer, it sends a cease and desist event signal to the other thread.

I'm using Mutex locks but am concerned about the remote possibility of the cease and desist signal arriving in-between the lower priority thread waking up and locking the Mutex.

My thoughts were to lock the Mutex then re-check the event signaling, however the manual states:

"You can use the os_evt_get function to identify the event that caused the os_evt_wait_or function to complete."

Can I be sure that this function will always return the latest set of events, even if they've not yet been used to wake a thread?

Many thanks

Parents
  • A couple of observations here:


    "I'm wishing to share a buffer between two threads of different priority. When the thread of higher priority wishes to use the buffer, it sends a cease and desist event signal to the other thread."

    First, when the higher priority thread needs to run, the RTOS will switch it in (it is the HIGHER priority than the other task, therefore preemption will occur). So, by definition, the lower task will not be running (ie: in pending state) nor actively accessing the buffer in question when the higher task is running (it could be 'in process' of using it when it was preempted though).

    "I'm using Mutex locks but am concerned about the remote possibility of the cease and desist signal arriving in-between the lower priority thread waking up and locking the Mutex."

    Second, in this case a Mutex does more harm than good for the reasons you mentioned (ie: locking out higher priority task from accessing the buffer).

    If these two tasks are sharing the buffer for read/write purposes (ie: one tasks reads while the other writes to the buffer) you could use a circular buffer with read(tail) and write(head)pointers. If both tasks have visibility to the pointers, then when they are equal there is no more data to read. If they are both reading/writing to the same buffer (ie common data as in a database type use) then tasks of equal priority might be the best route to go here. Since I don't know your actual design thats as far as I can go here.

Reply
  • A couple of observations here:


    "I'm wishing to share a buffer between two threads of different priority. When the thread of higher priority wishes to use the buffer, it sends a cease and desist event signal to the other thread."

    First, when the higher priority thread needs to run, the RTOS will switch it in (it is the HIGHER priority than the other task, therefore preemption will occur). So, by definition, the lower task will not be running (ie: in pending state) nor actively accessing the buffer in question when the higher task is running (it could be 'in process' of using it when it was preempted though).

    "I'm using Mutex locks but am concerned about the remote possibility of the cease and desist signal arriving in-between the lower priority thread waking up and locking the Mutex."

    Second, in this case a Mutex does more harm than good for the reasons you mentioned (ie: locking out higher priority task from accessing the buffer).

    If these two tasks are sharing the buffer for read/write purposes (ie: one tasks reads while the other writes to the buffer) you could use a circular buffer with read(tail) and write(head)pointers. If both tasks have visibility to the pointers, then when they are equal there is no more data to read. If they are both reading/writing to the same buffer (ie common data as in a database type use) then tasks of equal priority might be the best route to go here. Since I don't know your actual design thats as far as I can go here.

Children
More questions in this forum