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

[David Abrahams]

Dave Butenhof <david.butenhof at hp.com> writes:

> 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. 

Aww, c'mon.  You're seriously telling me that one thread can set the
"there's now an active cancellation flag" for another thread, and the
other thread can read it with _NO_ synchronization?  That isn't how I
learned things work by reading your book!

> 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".)

So now you're telling me that my mental model for what's required to
write this state in one thread and read it in another is all wrong,
and I should be thinking of it in some way that makes it
"asynchronous" despite the fact that it really is synchronous under
the covers?

This sound like you're just making it worse for "thought models," not
better.

> 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". ;-)

Yes, to you.  For the purposes of the big argument over how these
exceptions work, it's a completely irrelevant fact (if you can even
call it that, because the real facts of the matter have only become
blurrier as I read more of what you write).

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com