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

[Dave Butenhof]

David Abrahams wrote:
> 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!
>   
Cancellation state is a "stash and go" transaction; all that's necessary 
is visibility guarantees and a confidence that the storage can't go away 
in the midst. There are lots of lock free techniques. As far as my book 
advice goes, the point here is that there's no standard or portable API 
allowing application code to do this. It's "cake" for an implementation.
>> 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.
>   
No, never mind. I'll surrender. I'm clearly thinking at a level of 
abstraction and/or detail that doesn't matter to most people. Maybe it 
is just pointless confusion.

I've had a really busy couple of weeks and maybe I'm just blowing off a 
little steam in a nice technical argument. But if I'm arguing about 
something that doesn't matter to anyone but me, that's stupid.
>> 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)
OK, "least interesting" was mostly a joke, and the part that wasn't a 
joke was unnecessarily provocative. Sorry. I got carried away.
-------------- 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/eadff842/attachment.vcf>