Pthread behavior ~ pthread_cond_timedwait - VxWorks

This is a discussion on Pthread behavior ~ pthread_cond_timedwait - VxWorks ; Greetings, I have a Linux application that I am porting to VxWorks. I am noticing some strange behavior with pthread_cond_timedwait function. I am trying to get some feedback and references to any other VxWorks - pthreads wierdness. My Tornado/VxWorks version ...

+ Reply to Thread
Results 1 to 2 of 2

Thread: Pthread behavior ~ pthread_cond_timedwait

  1. Pthread behavior ~ pthread_cond_timedwait

    Greetings,

    I have a Linux application that I am porting to VxWorks. I am noticing
    some strange behavior with pthread_cond_timedwait function. I am trying
    to get some feedback and references to any other VxWorks - pthreads
    wierdness. My Tornado/VxWorks version is Tornado 2.2.1 / VxWorks 5.5.1

    The function of concern is:

    int pthread_cond_timedwait(pthread_cond_t *cond, pthread_mutex_t
    *mutex, const struct timespec *abstime);

    According to the POSIX spec abstime SHOULD BE some FUTURE clock time.
    {Pulled from Linux man pages} ... pthread_cond_timedwait atomically
    unlocks mutex and waits on cond, as pthread_cond_wait does, but it also
    bounds the duration of the wait. If cond has not been signaled within
    the amount of time specified by abstime, the mutex is re-acquired and
    pthread_cond_timedwait returns the error ETIMEDOUT.

    The abstime parameter specifies an absolute time (a fixed future clock
    time), with the same origin as functions time and gettimeofday (which
    come from #include and #include on Linux). An
    abstime of 0 corresponds to 00:00:00 GMT, January 1, 1970 ...

    FROM MY TESTS pthread_cond_timedwait on VxWorks uses relative time.
    That is, if you pass it 5 seconds it will time out in 5 seconds!

    pthread_cond_timedwait(cond, mutex, abstime /* Exactly 5 seconds, 0
    usecs */);

    This is a deviation from the POSIX spec ...

    The spec also says EITHER the condition is signaled OR the ABS timeout
    expires when the clock hits clocktime + desired_timeout_period.

    This (and other thread issue) are causing strange application behavior.
    The application works on Linux, on VxWorks it does not work. Yes I took
    all precautions in acquiring the lock before the call etc ...

    Any comments on this and pthreads on VxWorks would be great.

    Regards,
    Ama


  2. Re: Pthread behavior ~ pthread_cond_timedwait

    Hi:

    I'm not sure what's going on with your OS, but we wrote a thread
    library for use on both Solaris and vxWorks is it seems to work OK
    using pthread calls (see below).

    I looked at the code for pthread_cond_timedwait ... if the abstime is
    in the future (gt Tnow), them it computes the number of clock ticks
    required to get to your abstime, and does a semtake (vxWorks native
    call) with the number of ticks to wait for the semaphore.

    We did have an issue with the thread library with thread-related data
    that WRS sent us a fix for, but I don't think it was related to this.

    I not sure what else could be up, except maybe some confusion on the
    abstime when your system clock is set to 0.

    Good luck,
    LC


    bool
    ConditionVariable::
    wait(Time& time)
    {
    int result;
    struct timespec expiration;
    expiration.tv_sec = time.getSeconds();
    expiration.tv_nsec = time.getNanoSeconds();

    result = pthread_cond_timedwait(&m_conditionVar,
    m_mutex.getPosixMutex(),
    &expiration);
    if (!result)
    return false;

    if (result == ETIMEDOUT)
    return true;

    ostringstream message;
    message << "Failed to wait on condition variable: "
    << ", " << strerror(result)
    << " (" << result << ")";
    throw UtilsError("", m_className, message);
    }

    Ama|aye wrote:
    > Greetings,
    >
    > I have a Linux application that I am porting to VxWorks. I am noticing
    > some strange behavior with pthread_cond_timedwait function. I am trying
    > to get some feedback and references to any other VxWorks - pthreads
    > wierdness. My Tornado/VxWorks version is Tornado 2.2.1 / VxWorks 5.5.1
    >
    > The function of concern is:
    >
    > int pthread_cond_timedwait(pthread_cond_t *cond, pthread_mutex_t
    > *mutex, const struct timespec *abstime);
    >
    > According to the POSIX spec abstime SHOULD BE some FUTURE clock time.
    > {Pulled from Linux man pages} ... pthread_cond_timedwait atomically
    > unlocks mutex and waits on cond, as pthread_cond_wait does, but it also
    > bounds the duration of the wait. If cond has not been signaled within
    > the amount of time specified by abstime, the mutex is re-acquired and
    > pthread_cond_timedwait returns the error ETIMEDOUT.
    >
    > The abstime parameter specifies an absolute time (a fixed future clock
    > time), with the same origin as functions time and gettimeofday (which
    > come from #include and #include on Linux). An
    > abstime of 0 corresponds to 00:00:00 GMT, January 1, 1970 ...
    >
    > FROM MY TESTS pthread_cond_timedwait on VxWorks uses relative time.
    > That is, if you pass it 5 seconds it will time out in 5 seconds!
    >
    > pthread_cond_timedwait(cond, mutex, abstime /* Exactly 5 seconds, 0
    > usecs */);
    >
    > This is a deviation from the POSIX spec ...
    >
    > The spec also says EITHER the condition is signaled OR the ABS timeout
    > expires when the clock hits clocktime + desired_timeout_period.
    >
    > This (and other thread issue) are causing strange application behavior.
    > The application works on Linux, on VxWorks it does not work. Yes I took
    > all precautions in acquiring the lock before the call etc ...
    >
    > Any comments on this and pthreads on VxWorks would be great.
    >
    > Regards,
    > Ama



+ Reply to Thread