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

[Dave Butenhof]

David Abrahams wrote:

>Gabriel Dos Reis <gdr at integrable-solutions.net> writes:
>  
>
>>Such clear statement, from portability point of view, has different
>>impact than an unspoken assumption.
>>    
>>
>I think I heard what you were trying to say.  Maybe I'm just blind to
>the answer, but while I think it's possible (though usually
>unconstructive) to formally label a particular programming construct
>evil, I don't think it's possible to formally bless a programming
>construct.  Whether "catch-all without rethrow", or "while(1) loop
>without break", or "delete this", etc are going to be OK is dependent
>on program context, even if it is OK "in principle" in the POSIX
>environment.  What can a formal specification say to bless a
>programming construct that could, depending on how it's used, lead to
>undefined or otherwise bad behavior?
>  
>
We dealt with this sort of philosophical issue a lot in the POSIX 
working group. We had two vocal and often diametrically opposed factions 
(which, in retrospect, was probably good; though it did make for some 
quite "interesting" meetings): the "academic" faction who wanted to 
design a clean interface that would make it not only "obvious" how to 
write a "correct" program but also difficult to write an "incorrect" 
program; and the realtime ("hard" realtime, as in NASA & Navy) types who 
frequently HAD to do those things, knew how to, and wanted clean and 
portable mechanisms.

Either extreme is philosophically defensible, perhaps; but neither is 
practical. Real code needs to do things sometimes that aren't 100% safe, 
and solutions will be developed. You're not really helping any by 
forcing those solutions to be non-standard and non-portable. On the 
other hand, some "unusually" unsafe things may really be too dangerous 
for a general purpose interface. There's no hard and fast rule that can 
help in drawing that line; it's a case by case judgement call by the 
committee and balloters. (With the inevitable result that people 
complain "why didn't you do this, when you did THAT, which is just as 
bad or even worse"... well, because the committee that day saw it 
differently, for whatever reason.)

This appears to be the same sort of situation. I'm not even going to 
pretend to have an answer; and in fact I'd argue that nobody does (or 
can) have "the" answer... if there even is one. ;-)

Getting back into context, we're adding cancellation. It has special 
semantics. That conflicts with wide and sanctioned usage of catch(...) 
without rethrow; and somehow we need to deal with this. We can say that 
all such code is now officially busted even though it was in standard 
libraries, and perhaps even recommended. We can somehow adjust the model 
so that it "works" anyway, as by Jason's "re-cancel on exception 
destruct"; recognizing that it becomes less convenient to catch when you 
really want to, and that we'll have extra unwinding (and loss of 
debugging information) when it happens.

We could require the language to perform some call stack analysis as 
part of deciding whether to deliver a cancel in the first place -- which 
goes along with my earlier "random speculation" that the C++ concept of 
'cancel enabled' might be a dynamic property of the call stack rather 
than explicit API. I was thinking in terms of disabling cancel within a 
'throw()' scope... but there might be other conditions. For example, we 
could disable inside either 'throw()' or any try with a catch(...) that 
doesn't rethrow... unless there's an INNER scope that allows throwing 
cancel AND with an explicit catch(cancel). So a nothrow destructor 
(regardless of whether all destructors were implicitly nothrow or not) 
could allow "local" cancellation by nesting a try{} catch(cancel) {}.

(Sounds too complicated; but it's something to think about. ;-) )

-- 
/--------------------[ 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 ]---/