use CLOCK_MONOTONIC in sem_timed_wait to fix 2193

[JasonWang-Slamtec]

Issue #2193
version: 2.0.6

client process use the following function to control heatbeat interval

expected<SemaphoreWaitState, SemaphoreError> sem_timed_wait(iox_sem_t* handle, const units::Duration& timeout) noexcept
{
    const timespec timeoutAsTimespec = timeout.timespec(units::TimeSpecReference::Epoch);
    auto result = IOX_POSIX_CALL(iox_sem_timedwait)(handle, &timeoutAsTimespec)
                      .failureReturnValue(-1)
                      .ignoreErrnos(ETIMEDOUT)
                      .evaluate();
    if (result.has_error())
    {
        return err(sem_errno_to_enum(result.error().errnum));
    }
    return ok((result.value().errnum == ETIMEDOUT) ? SemaphoreWaitState::TIMEOUT : SemaphoreWaitState::NO_TIMEOUT);
}

If the system time jumps, this function will not work properly.
How about the following modification:

expected<SemaphoreWaitState, SemaphoreError> sem_timed_wait(iox_sem_t* handle, const units::Duration& timeout) noexcept
{
    //const timespec timeoutAsTimespec = timeout.timespec(units::TimeSpecReference::Epoch);
    const timespec timeoutAsTimespec = timeout.timespec(units::TimeSpecReference::Monotonic);
    auto result = IOX_POSIX_CALL(iox_sem_timedwait)(handle, &timeoutAsTimespec)
                      .failureReturnValue(-1)
                      .ignoreErrnos(ETIMEDOUT)
                      .evaluate();
    if (result.has_error())
    {
        return err(sem_errno_to_enum(result.error().errnum));
    }
    return ok((result.value().errnum == ETIMEDOUT) ? SemaphoreWaitState::TIMEOUT : SemaphoreWaitState::NO_TIMEOUT);
}

and in iox_sem_timedwait,

inline int iox_sem_timedwait(iox_sem_t* sem, const struct timespec* abs_timeout)  
{
     //return sem_timedwait(sem, abs_timeout);
      return sem_clockwait(sem, CLOCK_MONOTONIC, abs_timeout);
}

[JasonWang-Slamtec]

I tested it, and it works, but I'm not sure if it might introduce any regression bugs

[elfenpiff]

@JasonWang-Slamtec this is a great solution. Some years ago it was not available on all platforms we support but a quick google search makes me optimistic that we can add this today. So linux, qnx and freebsd should be easy, Windows and Mac Os do not support this so we need to find here another alternative.

Maybe we can do this step by step and first adjust the linux, qnx and freebsd platform and let the others run with a realtime clock. If you like you can create an issue and a pull request - I would be happy to review it!

[elBoberido]

If we do this, we need to rename iox_sem_timedwait to iox_sem_clockwait. Just using sem_clockwait will be confusing, since one would expect to pass a timeout related to the realtime clock.

Please have a look at 2.1 for a proposal to fix it also on other platforms
https://github.com/eclipse-iceoryx/iceoryx/wiki/2024-06-25-Eclipse-iceoryx-developer-meetup

[elBoberido]

@elfenpiff what do you think about having iox_sem_timedwait and iox_sem_clockwait in the platform and when sem_clockwait we set the errno to ENOSYS. The semaphore could then try to call iox_sem_clockwait and if ENOSYS is set, iox_sem_timedwait is called. We could then also print a warning or debug message when sem_clockwait is not available to inform the user about the potential issues. Furthermore, on safety critical systems, the iox_sem_clockwait call could just terminate if not supported and then it would be noticed when the tests fails, if this call is present in production code.

On the other hand, we also need to port away from the semaphore for platforms where we want to support 32-to-64-bit communication. So I'm not sure if it is worth to have this intermediate solution.

[elfenpiff]

@elBoberido I like your approach but I see also that we currently do not have the capacity to realize it.
So let's wait until we have implemented the 32-to-64-bit communication and maybe we can then remove the semaphore completely.

[gpalmer-latai]

Any update on your progress here? I saw the "spin wait" - is that the proposed alternative to the semaphore wait? We are also interested in moving away from relying upon the system clock here.