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.