From: terekhov (terekhov_at_[hidden])
Date: 2002-01-15 14:35:08
--- In boost_at_y..., "bill_kempf" <williamkempf_at_h...> wrote:
> --- In boost_at_y..., "terekhov" <terekhov_at_d...> wrote:
> > --- In boost_at_y..., "bill_kempf" <williamkempf_at_h...> wrote:
> > > --- In boost_at_y..., "terekhov" <terekhov_at_d...> wrote:
> > > > --- In boost_at_y..., "bill_kempf" <williamkempf_at_h...> wrote:
> > > > [...]
> > > > > Not true. All that would be required is to have the Boost
> > > > > synchronization primitives built on top of a complex
> condition
> > > > > variable that can watch both the state it's interested in
> (such
> > > as
> > > > a
> > > > > mutex being unlocked) and for a cancellation request.
> > > > > Trivial to implement
> > > > ^^^^^^^^^^^^^^^^^^^^
> > > >
> > > > Really? Perhaps then I did something wrong here:
> > > >
> > > > http://groups.google.com/groups?as_umsgid=3B0BA709.973337EB%
> > 40web.de
> > >
> > > I don't see anything wrong with what you did, though I didn't
> read
> > > the code too closely. What makes you assume you must have done
> > > something wrong because of what I just said?
> >
> > I thought that you mean something else (a *better*, "trivial"
> > solution) which would for example, NOT require locking of
> > TWO mutexes at the same time in a different order and thus,
> > would not need any trylock deadlock resolution. (Personally,
> > I am always become very suspicion when I see something like
> > this. To me, this is not something, which I would characterize
> > as "trivial").
>
> A single mutex and condition variable can be used. The
Boost.Threads
> mutex types just have to be implemented in a manner similar to how
> boost::timed_mutex is today.
Apropos boost::timed_mutex implementation.
PTHREADS Rationale says:
"<...examples...> Thus it has not yet been shown
that the full semantics of mutex locking with
timeout can be efficiently and reliably achieved
using existing interfaces."
regards,
alexander.