Re: first sight

From: bill_kempf (williamkempf_at_[hidden])
Date: 2002-01-17 12:38:47

--- In boost_at_y..., "Peter Dimov" <pdimov_at_m...> wrote:
> From: "David Abrahams" <david.abrahams_at_r...>
> > From: "terekhov" <terekhov_at_d...>
> >
> > > > I'm still trying to determine what should be a cancellation 
point
> > > and
> > > > what shouldn't.  That's why I'd really appreciate your 
writing up
> > > the
> > > > pros/cons of having the mutex lock be a cancellation point.  
I'm
> > > > fairly certain it shouldn't be, but at the very least I'll 
have to
> > > > document the rationale behind that decision.
> > >
> > > Just ask Peter whether he wants that his shared_ptr's
> > > ++ and -- would start throwing exceptions by default
> > > in thread-safe version of his class.
> >
> > Was Peter going to implement pointer arithmetic? I don't think 
so. Maybe
> you
> > mean when the reference-count is incremented/decremented? If so, 
I agree
> > that it would be a nearly disastrous design. That's why we can 
disable
> > cancellation, right? In response to my query about how efficient 
it might
> be
> > to disable cancellation you posted a big wad of code that I'm not
> qualified
> > to interpret**,
> 
> The point was that the cancellability property of a thread is not a 
thread
> local, therefore has to be protected by a mutex; so setcancelstate
() has a
> mutex lock inside it.

I'm not sure that was the point.  If it was, I don't know that it 
holds any meaning.  This implementation detail need not use the same 
mutex type, nor the same locking mechanism, so need not be a 
cancellation point and thus won't throw.  This does 
mean "significant" performance overhead when enabling/disabling the 
cancellability.

BTW, is it really true the cancellability is not thread local?  Can 
other threads actually change the cancellability of a thread?  You 
can't in POSIX and I don't see why you would here either.  The cancel 
request flag must be shared and protected, yes, but that's different 
state data.

> > but if it is too inefficient, we could:
> >
> > 1. go with Peter's proposal of an additional version of 
mutex_lock that is
> > not a cancellation point, or
> >
> > 2. we could say that if people want their mutex_lock to be a 
cancellation
> > point, they can call_check_for_cancellation manually before 
locking, or
> > write a wrapper.
> >
> > Which is the right answer?
> 
> (2) is. I'm now nearly convinced that the pthreads way is the 
correct way,
> and any deviation will prove to be a mistake. IOW I think that the 
standard
> C++ threading library should follow pthreads - in every aspect.

Not in every respect, though there should be fewer differences then 
there is now.  I'm working on that.

In any event, I'm fairly convinced of (2) as well, but I've yet to 
see rationale that will hold up.  (Or at least I've not understood 
something if the provided rationale holds up.)
 
> It's clear from Butenhof's posts in c.p.t that pthreads have been 
carefully
> specified to interact well with C++ implementations; for example, 
pthreads
> cancellation is based on an existing implementation that used C++
> exceptions, it's intended to play well with C++ exception handling
> (cancellation requests invoke destructors, C++ exceptions invoke 
pthreads
> cleanup handlers), and pthread_clenup_push/pop are intended to be
> (implementable as)

Intended, but not gauranteed, unfortunately.  In any event, a post 
from him copied on this list shows that there are still some 
considerations that should be made in C++ that go beyond that 
specified by POSIX.  And those considerations are exactly what we've 
been discussing.

Bill Kempf