Re: first sight

From: bill_kempf (williamkempf_at_[hidden])
Date: 2002-01-15 14:12:45

--- 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.

Bill Kempf