[c++-pthreads] Re: FW: RE: Re: I'm Lost

Dave Butenhof david.butenhof at hp.com
Wed Mar 8 20:59:48 UTC 2006


David Abrahams wrote:
> "Meredith, Alisdair" <Alisdair.Meredith at uk.renaultf1.com> writes:
>   
>> David Abrahams [mailto:dave at boost-consulting.com] wrote:
>>     
>>> Subject to cancelability.  In C++ "cancelability" would indicate
>>> whether cancellation points can throw (these asynchronously-initiated
>>> exceptions).  
>>>       
>> Sorry to jump into the middle of a good dialog with what might seem an
>> irrelevance, but how will these asynchronous exceptions (now being
>> re-thrown 'as sychronous') 
>>     
> Dave B: This is why I didn't want the term asynchronous in the
> discussion.  It's just a confusing distraction.
>   
Well, I guess it's a C++ viewpoint vs a threads viewpoint. When I see 
"synchronous" cross-thread exceptions, cancel or otherwise, my first 
thought has to be, so who is responsible for the synchronization, and 
how does it work?

The point is, though, that there IS no synchronization. That is, by 
definition, the communication protocol is asynchronous. (Actually, in 
pure POSIX cancellation is IS possible to "post" a cancel request 
without synchronization, unless you need to blast through a blocking 
operation. With a general cross-thread exception that's unlikely to be 
possible, but the synchronization is far below the application level, 
and provides no useful synchronous behavior for the application 
developer; which amounts to the same thing as "asynchronous".)

I can't possibly say "C++ does cross-thread exceptions synchronously", 
because it isn't a practical or useful definition, and wouldn't be a 
good operational model. The communication has to be asynchronous.

Only the final step, entirely within the target thread, is fully 
synchronous with that thread at a level that's of any use to the 
application model. The target detects at a cancellation/exception point 
that the request currently exists (registered asynchronously at some 
previous time ;-) ), and SYNCHRONOUSLY throws the exception into its own 
call stack.

So, yeah; the exception is synchronous. Fine. But that's only the final, 
and least interesting, step in the protocol. Or perhaps that's just 
"least interesting" to ME, because "I'm a thread guy". ;-)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: david.butenhof.vcf
Type: text/x-vcard
Size: 476 bytes
Desc: not available
URL: <http://sourcerytools.com/pipermail/c++-pthreads/attachments/20060308/50a359da/attachment.vcf>


More information about the c++-pthreads mailing list