Re: thread lib: solaris problems.

From: Gennadiy E. Rozental (rogeeff_at_[hidden])
Date: 2001-10-30 17:27:11

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.

Gennadiy.

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.

--- In boost_at_y..., williamkempf_at_h... wrote:
> --- In boost_at_y..., "Gennadiy E. Rozental" <rogeeff_at_m...> wrote:
> > EINVAL
> > 
> > > It would help if someone can determine precisely what error is 
> > being 
> > > returned here (in the name format instead of the integer 
> > equivalent).
> > > 
> > > Bill Kempf
> 
> OK, that's a starting point.  Unfortunately, I don't see how any of 
> the parameters can be considered invalid.  Especially since this 
same 
> code works on other POSIX/pthread platforms.
> 
> Let's try and assume that the guess about the implementation 
figuring 
> out there are no other running threads to signal the condition is 
the 
> culprit.  Can someone on Solaris modify the code such that a dummy 
> thread is created that simply sleeps for twice as long as we 
> timeout?  This should help to eliminate this guess as the culprit.
> 
> Bill Kempf