^{Originally posted by irowebbn August 1, 2023}
The cFE call for receiving a software bus message, CFE_SB_ReceiveBuffer, uses the OS_QueueGet call to manage the OS-level interface for the message passing. Unlike the RTEMS and VxWorks implementations, the POSIX implementation of OS_QueueGet uses an absolute timestamp from CLOCK_REALTIME to set the timeout periods to wait for a message. This appears to be because the POSIX mqueue API requires it..

The problem with basing the timeout off the absolute system clock rather than as a duration based on clock ticks (as RTEMS and Vxworks do), is that if they system clock changes, the timeout is affected. I have observed a situation if the system clock is updated (for example, after resetting the clock based on acquired GPS signal after being suspended) calls to CFE_SB_ReceiveBuffer that specify timeouts will be stuck forever if a message isn't sent. It is no longer possible to have task occur after a certain amount of time if a message isn't sent.

Describe the solution you'd like
OS_QueueGet call should still wake up after its indicated timeout even if/when CLOCK_REALTIME gets updated in the background.

Additional context
This is an underlying limitation with the POSIX API, the mq_timedwait call uses CLOCK_REALTIME as its reference. See https://stackoverflow.com/questions/33873374/pthreads-mq-timedreceive-pthread-cond-timedwait-and-clock-realtime

Requester Info
Originally from @irowebbn in cFS discussion