Re: thread lib: solaris problems.

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