Timed wait support in Os::ConditionVariable?

[ebenezerarunkumar]

I'm working on a component that needs a timed wait (e.g., wait up to 5 seconds for a signal, then proceed with error handling if it doesn't arrive). I would like to use the ConditionVariable interface but currently Os::ConditionVariable::pend() only supports indefinite blocking.

POSIX provides pthread_cond_timedwait() which should make this straightforward to implement on POSIX platforms. Similarly, other OS's like FreeRTOS also support this mechanism.

Proposed API addition:

// In Os::ConditionVariableInterface
Status pend(Os::Mutex& mutex, U32 timeoutMs);           

enum Status {
    OP_OK,   
    ERROR_MUTEX_NOT_HELD, 
    ERROR_DIFFERENT_MUTEX, 
    ERROR_NOT_IMPLEMENTED, 
    NOT_SUPPORTED,         
    TIMEOUT, // NEW - Returned when timeout expires before signal
    ERROR_OTHER         
};                                                                                                        

Potential use cases could be: Waiting for external hardware responses, inter-component synchronization with bounded wait times, and avoiding indefinite hangs in fault scenarios.

1. Is there interest in adding timeout support to the Os::ConditionVariable interface?
2. If not, what's the recommended fprime pattern for implementing timed waits?

[SterlingPeet]

In the past I have implemented timeouts with combination of a rate group portcall trigger and a comparison of the current time to the start time. I suspect this is the typical pattern, I have not yet run across a case where this did not work.

That said, I would like to see a neat timeout condition interface, I would use that for clarity of intent to the next developer.

[timcanham]

The one caution for checking expiration based on time is if there is a time update. We know of one team that had an unexpected action happen because they were checking based on system time and somebody updated the time to the future, causing the action to happen. If the timeout is along the lines of "timeout = sometime in the future relative to my time now," I think a countdown from a rate group like @SterlingPeet describes is the most robust, but the timout has to be on the same scale as the rate group. So, if your timeout is 10 seconds, counting down via a 1Hz rate group is fine. If your timeout is 10ms, you should use a hardware timer or something like it.