[c++-pthreads] thread-safety definition

[Dave Butenhof]

Alexander Terekhov wrote:

>Dave Butenhof wrote:
>[...]
>  
>
>>Nevertheless, async cancel CAN be used safely if you're careful, without
>>disrupting ...                                                   ^^^^^^^
>>    
>>
>  ^^^^^^^^^^
>
>Right.
>
>>Introducing asynchronous exceptions into C++ would be pointlessly
>>disruptive ...                                        ^^^^^^^^^^^
>>    
>>
>  ^^^^^^^^^^
>
>And that's the phobia hits DRB again.
>  
>
Several insults come to mind, but I'll bite my tongue. Alexander, you're 
either deliberately misusing, or just misunderstand, that word. Try 
looking it up in an English dictionary. Then try using it in a sentence 
where it actually belongs. After that, perhaps we can get back to 
talking about cancel and exceptions.

>>Even if it were supported, though, C++ is certainly free to follow the
>>lead of POSIX. We designated only a very few functions to be
>>async-cancel safe; and even at that I think we ended up with more than
>>we really should have had. (I never really figured out why we ended up
>>with pthread_cancel() being async-cancel safe, and I don't think it
>>makes any sense. The guy who write the text couldn't remember either,
>>    
>>
>Could it be that the intent was to make pthread_testcancel(), not
>pthread_cancel(), async-cancel-safe? ;-)
>  
>
No. First off, the only reason to use async-cancel, with the associated 
complications and risks, is that you're unwilling to pay the cost of 
calling pthread_testcancel() -- e.g., in a tight computational loop. If 
you are willing to call pthread_testcancel() anywhere you "really want a 
cancel" it'd be just silly to bother with async cancel at all. 
Furthermore, despite the looseness in the standard wording that allows 
implementations to ignore async cancel entirely or for long periods, 
this was never the intent. In any implementation of any approximation to 
what the working group would have accepted as "quality", there'd be no 
point at all in making the call when async cancel is enabled.

>>but in the end we decided not to risk changing it.) Really, in terms of
>>POSIX standard APIs, all you can do with async cancel enabled is to
>>DISABLE async-cancel. I like it that way. There's no reason at all that
>>ANY of the standard C++ runtime should be designated (or coded) to be
>>async-cancel safe.
>>    
>>
>C++ aside for a moment, I have yet to see async-cancel-UNsafe 
>implementation of, say, strlen(). Care to inspire me? TIA.
>  
>
Perhaps, but that's because you've looked. The point is that there's no 
way to know without reading the source. And even if you do, it may 
change on the next edit. You cannot safely PRESUME that anything at all 
is async cancel safe unless that's a documented characteristic of the 
function. Or, of course, if you wrote it yourself and are willing to bet 
that you didn't make any mistakes. ;-)

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