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