[c++-pthreads] Re: thread-safety definition

[Dave Butenhof]

Jason Merrill wrote:

>On Fri, 09 Jan 2004 07:20:18 -0500, Dave Butenhof <David.Butenhof at hp.com> wrote:
>  
>
>>Jason's model, putting together the puzzle pieces from various messages
>>here
>>    
>>
>My original formulation is at
>
>  http://www.codesourcery.com/archives/c++-pthreads/msg00059.html
>  
>
>>, appears to be basing cancel on an ordinary ("finalizable") C++
>>exception, which would be raised by any and all cancellation points; but if
>>the exception object were to be destroyed (by finalization), the "pending
>>cancel" would (might?) be reasserted. I personally feel that it ought to be
>>reasonable to finalize the cancel and continue operation. If that wasn't
>>really what the application intended then it's an application error; but
>>there are cases where it's arguably reasonable, and the capability falls
>>naturally out of the model.
>>    
>>
>Too naturally, IMO.  There seems to be a substantial amount of C++ code out
>there which traps and finalizes all exceptions, some of it in the C++
>standard library I/O classes.  I disagree with this design, and propose to
>change it in the message cited above, but it's just one example.  I don't
>think it's reasonable for a cancellation request to be silently discarded
>just because the thread was in the middle of doing some formatted output
>when the cancel was received.
>
>I wouldn't object to a facility for explicitly abandoning the cancel, but I
>think that allowing it to fall out of the model is far too fragile.
>
I think I disagree, at least philsophically, with the characterization 
of the model as "fragile". But I think I also understand what you mean; 
and the problem isn't with the model, but rather with the effect of that 
model on existing code that all-too-casually and agressively eats 
exceptions it doesn't understand. I think there are vanishingly few 
circumstances where a blind catch(...) without an unconditional re-throw 
should be considered "legitimate". If you don't completely understand 
what an exception means, you cannot claim to have completely recovered, 
and therefore cannot reasonably finalize propagation. (And when you 
catch anonymously, you can't possibly understand what they mean since 
you can't even identify them.) On the other hand, regardless of whether 
the semantics are meaningful or reasonable, the syntax is legal and 
apparently (unfortunately) in common use, so I can't dispute that you 
need to consider that.

>>Besides, "reasserting cancel" in all the right places and no other places
>>sounds like one of those projects that ends up being a lot more subtle
>>and error-prone than anyone ever expects. ;-)
>>    
>>
>Assuming support for abanoning the cancel, why would it be more complex than
>
>  pthread_cancel (pthread_self ());
>  
>
While I didn't have anything specific in mind, just a general concern, 
one example that occurs to me is "catch(...) {...; throw;}". One must be 
careful about specifying the "cancelled" state of the thread here; it 
shouldn't be possible to consider the exception destroyed during the 
body of the catch prior to the re-throw. I don't know if the current 
wording in the standard would allow this interpretation: but for 
"traditional" exceptions that have no "state" it shouldn't really 
matter, and it seems plausible that the standard doesn't tie this down 
explicitly. (It's enough in practice that the 'throw' continues 
propagation "as if". Now, though, the distinction might become critical.)

-- 
/--------------------[ David.Butenhof at hp.com ]--------------------\
| Hewlett-Packard Company       Tru64 UNIX & VMS Thread Architect |
|     My book: http://www.awl.com/cseng/titles/0-201-63392-2/     |
\----[ http://homepage.mac.com/dbutenhof/Threads/Threads.html ]---/