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
> > > > > variable that can watch both the state it's interested in
> > > 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
> > > 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
> 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."
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk