Re: first sight

From: bill_kempf (williamkempf_at_[hidden])
Date: 2002-01-16 10:14:16

--- In boost_at_y..., "terekhov" <terekhov_at_d...> wrote:
> --- In boost_at_y..., Lee Brown <lee_at_a...> wrote:
> [...]
> > Where is the flaw in the following?  I must be missing something 
> here.
> > 
> > class Lock {
> >  Lock(mutex& m) : m_(m) {
> >           disable_cancel();
> >           m_.lock();
> >           push_cleanup(m_ , &muxtex::unlock)
> >           enable_cancel();
> >  }
> > 
> >  ~Lock() { 
> > 	disable_cancel();
> > 	pop_cleanup(); 
> > 	enable_cancel();
> >    }
> 
> Perhaps you miss just one rather simple thing. We are not 
> supposed to wait on mutex - condition variables are designed 
> for waits. Now, when our threads return from cond.wait (even 
> if wait was cancelled), mutex is *always* locked. I just fail 
> to understand how it is supposed to work if mutex would itself 
> be a cancel.point! I need mutex on cancel to restore shared 
> data invariants (waiters count, etc...) So, what is the point 
> in making e.g. monitor lock a cancel.point by default if I 
> could always invoke pthread_testcancel() if I really want 
> it, and again - NOT SUPPOSED TO SPEND TOO MUCH TIME ON MUTEX 
> to make it worth being a cancel.point.

Alexander, it would be helpful if you could provide a writeup of all 
of the cons of making mutex locks a cancellation point.  I trust that 
it is, since POSIX avoided it, but we need the facts about why before 
we can decide anything ourselves.

Bill Kempf