|
Boost : |
From: terekhov (terekhov_at_[hidden])
Date: 2002-01-15 14:00:09
--- 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").
regards,
alexander.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk