Boost logo

Boost :

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


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.


P.S. EINVAL Source:

           The value specified by cond, mutex, or abstime is
           Different mutexes were supplied for concurrent
           pthread_cond_wait() or pthread_cond_timedwait() opera-
           tions on the same condition variable.
           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:
> >
> > > 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
> code works on other POSIX/pthread platforms.
> Let's try and assume that the guess about the implementation
> out there are no other running threads to signal the condition is
> 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

Boost list run by bdawes at, gregod at, cpdaniel at, john at