Re: first sight

From: terekhov (terekhov_at_[hidden])
Date: 2002-01-16 07:56:23

--- 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.
 
regards,
alexander.