Message Receive timeout if system clock changes?

[irowebbn]

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.

What's the recommended way of dealing with this? Do I somehow need to send messages to all pending receives after the system time is updated so that they get unblocked? Do I need to restart my apps after changing system time?

[jphickey]

Thanks for reporting this! This indeed is a problem with the underlying posix API. I looked into it and there may be some methods to get it to use CLOCK_MONOTONIC instead of CLOCK_REALTIME. Will write up an issue over in OSAL and maybe we can do something there.

In the meantime - yes, if you send a benign message (like a no-op command or something) that should wake up the task and get it unblocked. In practice, most CFE SB pipes have some periodic traffic so that's probably why this anomaly hadn't been observed.

[jphickey]

Submitted nasa/osal#1401

[irowebbn]

Excellent. thanks for filing the issue. Making sure a regular message is sent is not a problem since we are using a scheduler application. The particular case where I observed this was in HS, so I'd like to make sure that it still runs regularly even in the case when a wakeup message is not received (in case something goes wrong with the scheduler, for example).