Boost logo

Boost :

From: Gennadiy E. Rozental (rogeeff_at_[hidden])
Date: 2001-10-31 17:58:28


Hi,

I solved it. The problem is with third parameter nonoseconds should
not exceed 999999999. Run fillowing program ~ 50 times and you will
see what I mean.

#include <pthread.h>
#include <errno.h>
#include <stdio.h>

int main(int, char*[])
{
    timespec ts;
    clock_gettime(CLOCK_REALTIME, &ts);
    ts.tv_nsec += 100000000;

    pthread_mutex_t m_mutex;
    pthread_cond_t m_condition;

    pthread_mutex_init( &m_mutex, 0 );
    pthread_cond_init( &m_condition, 0 );
   
    switch( pthread_cond_timedwait(&m_condition, &m_mutex, &ts ) ) {
    case 0:
        printf( "OK\n" );
        break;
    case ETIMEDOUT:
        printf( "TIMEOUT: nsec: %d\n", ts.tv_nsec );
        break;
    case EINVAL:
        printf( "EINVAL: nsec: %d\n", ts.tv_nsec );
        break;
    }

    return 0;
}

Gennadiy.

--- In boost_at_y..., williamkempf_at_h... wrote:
> --- In boost_at_y..., "Gennadiy E. Rozental" <rogeeff_at_m...> wrote:
> > Hi,
> >
> > A little bit more information. Assert firing while processing
check
> > in line 131, for the test_timedlock<mutex>(). All other top level
> > tests does not affect it. The only nuance is that now error
became
> > not stable what means that assert fired only sometimes. Ant
ideas?
> If
> > I will have time I will try to play more with it.
>
> Sorry, no, I don't have any ideas. Thanks for reporting your
> findings, though. It may well be helpful in fixing the problem
> eventually.
>
> > P.S. EINVAL Source:
> >
> > EINVAL
> > The value specified by cond, mutex, or abstime is
> > invalid.
> > EINVAL
> > Different mutexes were supplied for concurrent
> > pthread_cond_wait() or pthread_cond_timedwait() opera-
> > tions on the same condition variable.
> > EINVAL
> > The mutex was not owned by the current thread at the
> > time of the call.
>
> This is precisely the description given in Butenhof's book, and
none
> of the reasons *seem* to apply here. :(
>
> Bill Kempf


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk